Уровень изоляции

Уровень изоляции

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

В Firebird уровень изоляции может быть:

* READ COMMITTED:

• RECORD_VERSION;

• NO RECORD_VERSION;

* SNAPSHOT;

* SNAPSHOT TABLE STABILITY.

Стандартные уровни изоляции

Стандарт SQL по изоляции транзакций "симпатизирует" механизму двухфазной блокировки, которую использует большинство реляционных СУБД для реализации изоляции. Это является его отличительной чертой по сравнению с большинством других стандартов. Он определяет изоляцию не столько в теоретических терминах, сколько в терминах феноменов, допускаемых каждым уровнем (или запрещаемых им). Феноменами, с которыми имеет дело стандарт, являются:

* "грязное" чтение (Dirty read): появляется, если транзакция способна читать неподтвержденные (ожидающие завершения) изменения, выполненные другими транзакциями;

* неповторяемое чтение (Non-repeatable read): появляется, если последующие чтения набора строк в рамках этой же транзакции могут отличаться от того, что было прочитано транзакцией в начале ее работы;

* фантомные строки (Phantom rows): появляется, если последующий набор строк, прочитанный транзакцией, отличается от набора, который был прочитан в начале работы транзакции. Фантомные явления появляются, если при последующем чтении появляются новые добавленные строки и/или исчезают удаленные строки, которые были подтверждены с момента первого чтения.

В табл. 26.1 показаны определяемые в стандарте четыре уровня изоляции с явлениями, которые управляют их определениями.

READ UNCOMMITTED вовсе не поддерживается в Firebird, READ COMMITTED соответствует стандарту. На двух следующих уровнях этого уровня изоляции природа многоверсионной архитектуры превалирует над ограничениями двухфазной блокировки, предлагаемой стандартом. Отображение указанных в стандарте уровней REPEATABLE READ и SERIALIZABLE невозможно.

Таблица 26.1. Уровни изоляции и управление феноменами в стандарте SQL

Уровень изоляции

"Грязное"чтение

Неповторяемое чтение

Фантомы

READ UNCOMMITTED

Допустимо

Допустимо

Допустимо

READ COMMITTED

Недопустимо

Допустимо

Допустимо

REPEATABLE READ

Недопустимо

Недопустимо

Допустимо

SERIALIZABLE

Недопустимо

Недопустимо

Недопустимо

READ COMMITTED

Самым низким уровнем изоляции является READ COMMITTED. Только на этом уровне изоляции вид состояния базы данных, измененного в процессе выполнения транзакции, изменяется каждый раз, когда подтверждаются версии записей. Вновь подтвержденная версия записи заменяет ту версию, которая была видна при старте транзакции. Подтвержденные добавления, выполненные после старта транзакции, становятся видимыми для нее.

Уровень изоляции READ COMMITTED обеспечивает неповторяемое чтение и не избавляет от феномена фантомных строк. Это наиболее полезный уровень для операций реального времени над большим объемом данных, т. к. сокращается количество конфликтов данных, однако он не является подходящим для задач, которым нужен воспроизводимый вид.

Поскольку уровень изоляции READ COMMITTED имеет скоротечную природу, то транзакция (именно этого уровня) может быть сконфигурирована в соответствии с потребностями реагирования на подтверждение изменений и наличие ожидающих завершения изменений других транзакций.

* При установке RECORD_VERSION (флаг по умолчанию) сервер позволяет транзакции читать самую последнюю подтвержденную версию записи. Если транзакция имеет режим READ WRITE (чтение/запись), то она будет способна перезаписывать самую последнюю подтвержденную версию записи, если ее идентификатор (TID) более поздний, чем идентификатор транзакции, подтвердившей самую последнюю версию записи.

* При установке NO_RECORD_VERSION сервер эффективно имитирует поведение систем, которые используют двухфазную блокировку для управления параллельностью. Он блокирует для текущей транзакции чтение строки, если для нее существует изменение, ожидающее завершения. Разрешение ситуации зависит от установки разрешения блокировки.

• При задании WAIT транзакция будет ждать, когда другая транзакция либо подтвердит, либо отменит свои изменения. Эти изменения затем станут доступными, если другая транзакция их отменит или если идентификатор транзакции более поздний, чем идентификатор другой транзакции. Транзакция будет завершена аварийно по конфликту блокировки, если идентификатор другой транзакции будет более поздним.

При задании NOWAIT транзакция немедленно получит сообщение о конфликте блокировки.

! ! !

ПРИМЕЧАНИЕ. Транзакция READ COMMITTED может видеть все последние подтвержденные версии, которые позволяют читать установки этой транзакции, что подходит для операций добавления, изменения, удаления и выполнения. При этом любые выходные наборы, полученные в транзакции по оператору SELECT, должны получать измененный вид базы данных.

. ! .

SNAPSHOT (параллельность)

"Средним" уровнем изоляции является SNAPSHOT, альтернативно называемый Repeatabie Read (повторяемое чтение) или concurrency (параллельность). При этом изоляция SNAPSHOT В Firebird не является в точности соответствующей уровню Repeatabie Read, как он определен в стандарте. Он изолирует вид базы данных для транзакции изменениями на уровне строк только для существующих строк. При этом, поскольку по своей природе многоверсионная архитектура полностью изолирует транзакции SNAPSHOT от новых строк, подтвержденных другими транзакциями, не предоставляя транзакциям SNAPSHOT доступ к глобальному образу состояния транзакций (TSB, см. главу 25), транзакции SNAPSHOT не могут видеть фантомные строки. Следовательно, транзакции SNAPSHOT В Firebird предоставляют более глубокий уровень изоляции, чем REPEATABLE READ В SQL.

Пока SNAPSHOT еще не идентичен SERIALIZABLE, потому что другие транзакции могут изменять и удалять строки, которые находятся в зоне видимости транзакции SERIALIZABLE.

Транзакция гарантирует неизменный вид базы данных, который до завершения транзакции не будет зависеть от любых подтвержденных изменений в других транзакциях. Такой уровень полезен для "исторических" задач, таких как формирование отчетов или экспорт данных, которые могут оказаться ошибочными, если не будут выполняться с воспроизводимым видом данных.

SNAPSHOT является уровнем изоляции по умолчанию для инструмента обработки запросов isql, а также для многих компонентов и драйверов интерфейса.

SNAPSHOT TABLE STABILITY (согласованность)

Самым "глубоким" уровнем изоляции является SNAPSHOT TABLE STABILITY, альтернативно называемый consistency, потому что он гарантирует получение данных в неизменном состоянии, который останется внешне согласованным в пределах базы данных, пока продолжается транзакция. Транзакции чтения/записи не могут даже читать таблицы, которые блокируются транзакцией с таким уровнем изоляции.

Блокировка на уровне таблицы, создаваемая этим уровнем изоляции, включает в себя все таблицы, к которым осуществляет доступ транзакция, включая те, которые связаны ссылочными ограничениями.

Этот уровень устанавливает агрессивное расширение, которое гарантирует сериализацию в строгом смысле, т. е. никакая другая транзакция не может добавлять или удалять - вообще изменять - строки в используемых таблицах, если любая транзакция получает дескриптор с этим уровнем изоляции. Наоборот, транзакция TABLE STABILITY не сможет получить дескриптор, если какая-нибудь транзакция чтения/записи в настоящий момент читает любую таблицу, которая находится в зоне видимости этой транзакции. В терминах стандарта это не обязательно, поскольку изоляция SNAPSHOT уже защищает транзакции от всех трех феноменов, управляемых уровнем SERIALIZABLE в стандарте SQL.

Транзакция consistency еще называется блокирующей транзакцией, потому что она блокирует доступ любых других транзакций чтения/записи к любым записям, к которым эта транзакция обращается, и к любым записям, зависящим от этих записей.

! ! !

ВНИМАНИЕ! Поскольку этот уровень потенциально блокирует часть базы данных для других пользователей, которым нужно выполнять изменения, SNAPSHOT TABLE STABILITY должен использоваться осторожно. Внимательно следите за размером применяемых наборов, воздействием на соединения, зависимые таблицы и особенно за длительностью такой транзакции.

. ! .