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

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

1. Отсутствие потерянных изменений. Рассмотрим следующий сценарий совместного выполнения двух транзакций: Транзакция 1 изменяет объект А базы данных. До завершения транзакции 1транзакция 2 так же изменяет объект 2. Транзакция 2 завершается оператором rollback например по причине нарушения ограничений целостности. Тогда при повторном чтении объекта А транзакция 1не видит изменений этого объекта, произведенных ранее. Такая ситуация называется ситуацией потерянных изменений и она противоречит требованию изолированности пользователей. Чтобы избежать такой ситуации транзакция 1 требуется чтобы до завершения транзакции 1 никакая другая транзакция не могла изменять объект А. Отсутствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.

2. Отсутствие чтения грязных данных. Рассмотрим следующий сценарий совместного выполнения транзакции 1 и 2. Транзакция 1 изменяет объект А базы данных. Параллельно с этим транзакция 2 читает объект А. Поскольку операция изменения еще не завершена транзакция 2 видит несогласованные грязные данные. Это так же не соответствует изолированности пользователя. Чтобы избежать чтения грязных данных до завершения транзакции 1 изменявшей объект А никакая другая транзакция не должна читать объект А. ( минимальным требованием является блокировка чтения объекта А до завершения операции его изменения транзакции 1).

3. Отсутствие неповторяющихся чтений. рассмотрим следующий сценарий совместного выполнения транзакций 1 и 2. Транзакция 1 читает объект А базы данных. До завершения транзакции 1 транзакция 2 изменяет объект А и успешно завершается оператором commit. Транзакция 1 повторно читает объект А и видит его измененное состояние. Чтобы избежать неповторяющихся чтений до завершения транзакции 1

Существует возможность обеспечения разных уровней изолированности для разных транзакций выполняющихся в одной системе. Для поддержания целостности достаточен первый уровень. При этом удается существенно сократить накладные расходы СУБД и повысить общую эффективность. К более тонким проблемам изолированности транзакций относится так называемая проблема «кортежей-фантомов», вызывающая ситуации, которые так же противоречат изолированности пользователя. Рассмотрим следующий сценарий. Транзакция 1 выполняет оператор А выборки кортежей отношения R с условием выборки S, т.е. выбирает часть кортежей отношения R, удовлетворяющий условию S. До завершения транзакции 1 транзакция 2 выставляет

Транщакция 1 повторно выполняет оператор А и в результате появляется кортеж, который отсутствовал при первом выполнении оператора А. Такая ситуация противоречит идее изолированности транзакций и может противоречить изолированности транзакций и может возникнуть даже на 3-м уровне изолированности транзакций. Чтобы избежать появления

Идея такой синхронизации – предикатные синхронизационные захваты. Известные давно, но в большинстве систем не реализованы.