Изолированность пользователей

Во многопользовательских системах с одной базой данных одновременно могут работать несколько пользователей или прикладных программ. Предельной задачей системы является обеспечение изолированности пользователей, т.е. создание достоверной и надежной иллюзии того, что каждый из пользователей работает с БД в одиночку.

В связи со свойством сохранения целостности БД транзакции являются подходящими единицами изолированности пользователей. Действительно, если с каждым сеансом работы с базой данных ассоциируется транзакция, то каждый пользователь начинает работу с согласованным состоянием базы данных, т.е. с таким состоянием, в котором база данных могла бы находиться, даже если бы пользователь работал с ней в одиночку.

При соблюдении обязательного требования поддержания целостности базы данных возможны следующие уровни изолированности транзакций:

1. Изменение объекта только одной транзакцией (отсутствие потерянных изменений)
2. Чтение только неизменяемого в данный момент объекта (отсутствие чтения «грязных данных»)
3. Изменение только нечитаемого в данный момент объекта (отсутствие неповторяющихся чтений)

• Первый уровень - отсутствие потерянных изменений. Рассмотрим следующий сценарий совместного выполнения двух транзакций. Транзакция 1 изменяет объект базы данных. До завершения транзакции 1 транзакция 2 также изменяет объект. Транзакция 2 откатывается (например, по причине нарушения ограничений целостности). Тогда при повторном чтении объекта транзакция 1 не видит изменений этого объекта, произведенных ранее. Такая ситуация называется ситуацией потерянных изменений. Естественно, она противоречит требованию изолированности пользователей. Чтобы избежать такой ситуации в транзакции 1 требуется, чтобы до завершения транзакции 1 никакая другая транзакция не могла изменять объект. Отсутствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.
• Второй уровень - отсутствие чтения "грязных данных ". Рассмотрим следующий сценарий совместного выполнения транзакций 1 и 2. Транзакция 1 изменяет объект базы данных. Параллельно с этим транзакция 2 читает объект. Поскольку операция изменения еще не завершена, транзакция 2 видит несогласованные "грязные" данные (в частности, операция транзакции 1 может быть отвернута при проверке немедленно проверяемого ограничения целостности). Это тоже не соответствует требованию изолированности пользователей (каждый пользователь начинает свою транзакцию при согласованном состоянии базы данных и в праве ожидать видеть согласованные данные). Чтобы избежать ситуации чтения "грязных" данных, до завершения транзакции 1, изменившей объект, никакая другая транзакция не должна читать объект (минимальным требованием является блокировка чтения объекта до завершения операции его изменения в транзакции 1).
• Третий уровень - отсутствие неповторяющихся чтений. Рассмотрим следующий сценарий. Транзакция 1 читает объект базы данных. До завершения транзакции 1 транзакция 2 изменяет объект и успешно завершается. Транзакция 1 повторно читает объект и видит его измененное состояние. Чтобы избежать неповторяющихся чтений, до завершения транзакции 1 никакая другая транзакция не должна изменять объект. В большинстве систем это является максимальным требованием к синхронизации транзакций.

Для поддержания целостности достаточен первый уровень.

Между транзакциями могут существовать следующие виды конфликтов:

• W-W - транзакция 2 пытается изменять объект, измененный не закончившейся транзакцией 1;
• W-R - транзакция 2 пытается читать объект, измененный не закончившейся транзакцией 1.
• R-W - транзакция 2 пытается изменять объект, прочитанный не закончившейся транзакцией 1;

Дата добавления: 2014-01-03