Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

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

Транзакции и MGA

MGA (Multi-Generational Architecture, многоверсионная архитектура) является названием основной архитектурной модели управления состоянием базы данных Firebird.

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

Пересылка в сравнении с COMMIT

Термин "пересылка" (post), вероятно, был заимствован у старых настольных бухгалтерских программ в качестве аналога пересылаемых журналов в бухгалтерских системах. Такая аналогия полезна для различения двух разделенных операций записи обратимых изменений в базу данных (при выполнении оператора) и подтверждения всех изменений, выполненных одним или несколькими операторами. Отправленные изменения невидимы за пределами их контекста транзакции и могут быть отменены. Подтвержденные изменения являются постоянными и становятся видимыми в запускаемых впоследствии транзакциях.

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

! ! !

ПРИМЕЧАНИЕ. Вызовы клиентом COMMIT или ROLLBACK являются единственно возможными способами завершения транзакции, Ошибки при подтверждении не означают, что сервер выполнит откат транзакции.

. ! .

Откат

Откат (rollback) никогда не завершается с ошибкой. Он отменит все изменения, которые были запрошены в процессе выполнения транзакции, - изменения, которые привели к исключениям, так же как и изменения, которые были успешными и не вызвали исключения.

Некоторые отмененные транзакции не оставляют образов строк на диске. Например, некоторые отмены вызывают на сервере просто исчезновение работы, выполненной триггерами, и образы строк, созданные при добавлении данных, естественным образом уничтожаются в процессе отмены вместе с автоматически отмененным протоколом, который поддерживается для добавления. Если одна транзакция добавляет большое количество записей, автоматически отмененный протокол будет уничтожен вместе с результатами, образы которых отмена будет оставлять на диске. Другие условия, при которых образы добавляемых записей могут оставаться на диске, - это крах сервера в процессе выполнения операции или использование установок транзакции, которые явно требуют "не отменять автоматически"[89].

Блокировка строки

В MGA наличие ожидающих завершения новых версий строки имеет следствием блокировку строки. При большинстве условий наличие новой подтвержденной версии блокирует запрос на изменение или удаление этой строки - это конфликт блокировки.

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

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

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

! ! !

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

. ! .

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

Во время успешного подтверждения старая версия записи становится устаревшей записью.

* Если выполнялась операция изменения, то новый образ становится самой последней подтвержденной версией. Оригинальный образ этой записи с идентификатором последней изменяющей транзакции становится доступным для сборки мусора.

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

Сведения о чистке и сборке мусора см. в разд. "Гигиена базы данных" главы 15. Руководство по чистке находится в главе 39.

В итоге при нормальных условиях:

* любая транзакция может читать любую строку, которая была подтверждена до старта этой транзакции;

* любая транзакция чтения/записи может запрашивать изменение или удаление строки;

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

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

Блокировка на уровне таблицы

Транзакция может быть сконфигурирована для блокирования всей таблицы. Существует два приемлемых способа сделать это в DSQL: установив уровень изоляции транзакции в SNAPSHOT TABLE STABILITY (известный также как согласованный режим, поддерживаемый повторяемым чтением, repeatable read) или с помощью резервирования таблицы. Следует подчеркнуть, что такие настройки нужны в случае, когда требуются приоритетные условия. Они не рекомендуются для ежедневного использования в Firebird.

Неприемлемый способ установления блокировки на уровне таблицы (Firebird 1.5 и выше) - применение пессимистической блокировки на уровне оператора, которая действует на всю таблицу. Оператор подобный следующему делает это:

SELECT * FROM ATABLE

FOR UPDATE WITH LOCK;

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

Добавление

Не существует "дельт" или блокировок для добавления. Если другая транзакция перед этим не выполняла добавления в условиях блокировки на уровне таблицы, добавление всегда будет успешным, если оно не нарушает каких-либо ограничений или проверок достоверности.

"Старение" и статистика транзакций

Когда клиентский процесс передает дескриптор транзакции, он получает уникальный внутренний идентификатор для транзакции и сохраняет его в инвентарной странице транзакции (Transaction Inventory Page, TIP).

Идентификатор и возраст транзакции

Идентификатор транзакции является 32-битовым целым, которое генерируется с единичным приращением. Новая или только восстановленная база данных начинает Серию идентификаторов с единицы. Возраст транзакции определяется ее идентификатором: самая старая имеет наименьший идентификатор.