Изолированность пользователей в многопользовательских системах
В многопользовательских системах с одной базой данных одновременно могут работать несколько пользователей или прикладных программ. Задачей системы является обеспечение изолированности пользователей, то есть создание достоверной и надёжной иллюзии того, что каждый из пользователей работает с базой данных в одиночку. В связи со свойством сохранения целостности базы данных транзакции являются подходящими единицами изолированности пользователей. Действительно, если с каждым сеансом работы с базой данных ассоциируется транзакция, то каждый пользователь начинает работу с согласованным состоянием базы данных, то есть с таким состоянием, в котором база данных могла бы находиться, даже если бы пользователь работал с ней в одиночку. При соблюдении обязательного требования поддержания целостности базы данных возможны следующие уровни изолированности транзакций:
Первый уровень изолированности пользователей – отсутствие потерянных изменений. Здесь будем считать, что пользователь или транзакция запускаемая пользователем одно и то же. Рассмотрим следующий сценарий совместного выполнения двух транзакций. Транзакция первая изменяет объект базы данных А. До завершения первой транзакции, вторая транзакция, как и первая транзакция, изменяет тот же объект базы данных А, и вторая транзакция завершается оператором ROLLBACK (например, по причине нарушения ограничений целостности). Тогда, при повторном чтении объекта базы данных, транзакция 1 не видит изменений этого объекта, произведённых ранее. Такая ситуация называется ситуацией потерянных изменений и противоречит требованию изолированности пользователей. Чтобы избежать такой ситуации для первой транзакции требуется, чтобы до ее завершения никакая другая транзакция не могла изменять объект А. Отсутствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.
Второй уровень изолированности пользователей – отсутствие чтения “грязных данных”. Рассмотрим следующий сценарий совместного выполнения транзакций 1 и 2. Транзакция 1 изменяет объект базы данных А, параллельно с этим транзакция 2 читает тот же объект базы данных. Поскольку операция изменения ещё не завершена, транзакция 2 видит несогласованные “грязные” данные. Это тоже не соответствует требованию изолированности пользователей, так как каждый пользователь начинает свою транзакцию при согласованном состоянии базы данных, и ожидает увидеть согласованные данные. Чтобы избежать ситуации чтения “грязных” данных, до завершения транзакции 1, изменившей объект А, никакая другая транзакция не должна читать объект А (необходимо выполнить блокировку чтения объекта А до завершения операции его изменения в транзакции 1).
Третий уровень изолированности пользователей – отсутствие неповторяющихся чтений. Рассмотрим следующий сценарий. Транзакция 1 читает объект базы данных А, и до ее завершения транзакция 2 изменяет объект А и успешно завершается оператором COMMIT. Транзакция 1 повторно читает объект А и видит его изменённое состояние. Чтобы избежать неповторяющихся чтений, до завершения транзакций 1 никакая другая транзакция не должна изменять объект А. В большинстве систем это является максимальным требованием к синхронизации транзакций, хотя, отсутствие неповторяющихся чтений ещё не гарантирует реальной изолированности пользователей.
Существует возможность обеспечения разных уровней изолированности для разных транзакций, выполняющихся в одной системе баз данных. Существует ряд приложений, для которых первого уровня изолированности пользователей достаточно (например, прикладные и системные утилиты, для которых некорректность индивидуальных данных несущественна). При этом удаётся существенно сократить накладные расходы СУБД и повысить общую эффективность.
К более тонким проблемам изолированности транзакций относится так называемая проблема кортежей – “фантомов” (четвертый уровень изолированности пользователей), вызывающая ситуации, которые также противоречат изолированности пользователей. Рассмотрим следующий сценарий. Транзакция 1 выполняет оператор выборки кортежей отношения R с условием выборки S (то есть, выбирается часть кортежей отношения R, удовлетворяющих условию S). До завершения транзакции 1 транзакция 2 вставляет в отношение R новый кортеж r, удовлетворяющий условию S, и успешно завершается. Транзакция 1 повторно выполняет оператор А, и в результате появляется кортеж, который отсутствовал при первом выполнении оператора (фантом). Такая ситуация также противоречит идее изолированности транзакций и может возникнуть даже на третьем уровне изолированности транзакций. Чтобы избежать появления кортежей–фантомов, требуется более высокий “логический” уровень синхронизации транзакций. Идеи такой синхронизации (предикатные синхронизационные захваты) известны давно, но в большинстве систем не реализованы