Многопользовательский режим
При работе СУБД ЛИНТЕР в однопользовательском режиме не возникает проблем, характерных при взаимодействии двух и более клиентских приложений. В случае многопользовательского режима возникают специфические проблемы, которые СУБД должна предотвращать. Например, это могут быть логические ошибки клиентских приложений, приводящие к потере данных или некорректному построению отчетов.
Таких проблем немного. Если рассматривать весь набор операций с объектами БД, как операции чтения (READ) и записи (WRITE), то в случае двух пользователей различных комбинаций последовательного выполнения двух операций всего четыре:
-
READ – READ;
-
READ – WRITE;
-
WRITE – READ;
-
WRITE – WRITE.
В первом случае проблемной ситуации не возникает, т.к. последовательное чтение данных не приводит к их противоречивости. Проблемы возникают при выполнении операции записи, которая выполняется в результате SQL-запросов INSERT, DELETE, UPDATE.
Рассмотрим каждую из конфликтных ситуаций. Будем обозначать символами T1, T2 соответственно транзакции, выполняющиеся первым и вторым пользователем, а символом A – объект БД, который изменяется (например, запись) клиентским приложением или разными нитями (таблица 5).
Конфликт | Описание |
---|---|
T1 WRITE A T2 READ A T1 WRITE A |
Конфликт в том, что транзакция T2 прочитала содержимое объекта A на момент выполнения, когда он находится не в окончательном состоянии (до подачи COMMIT). Такой конфликт называется «грязным» чтением (dirty read). Эту ситуацию можно получить, выполняя построение отчета во время активной модификации БД сложными расчетами. |
T1 READ A T2 WRITE A T1 WRITE A |
Конфликт состоит в том, что транзакция T2 потеряла свои изменения до момента своего завершения. Такой конфликт называется «потерянным изменением» (lost update). Примером создания такой ситуации является попытка одновременной работы по изменению банковского счета, изменению количества товара на складе и т.д. |
T1 READ A T2 WRITE A T1 READ A |
Конфликт в том, что транзакция T1, выполняя повторно операцию чтения данных до завершения транзакции, получает новые (измененные) значения. Такой конфликт называется «неповторяемое чтение» (unrepeatable read). Проявление конфликта возможно при построении сложных отчетов, многократно обращающихся к БД, при одновременной ее модификации. |
В СУБД ЛИНТЕР поддерживается пессимистичный (PESSIMISTIC
) режим работы с
транзакциями. При этом необходимо понимать, что желание избежать всех
конфликтов в СУБД требует больших вычислительных расходов.
Примечание
Все DDL-операторы (операторы определения данных, например, создание таблицы) автоматически приводят к выполнению оператора COMMIT и не могут быть отменены СУБД.