Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

Устойчивость

Когда транзакция завершается, ее изменения должны быть устойчивыми - т. е. новое состояние всех объектов, видимых другим транзакциям после подтверждения, будет сохранено и будет постоянным, независимо от наличия ошибок в оборудовании или краха программного обеспечения.

Контекст транзакции

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

Одна транзакция, много запросов

В Firebird любая операция, запрашиваемая клиентом, должна появиться в контексте какой-либо активной транзакции. Одна транзакция в своих границах может включать один или много клиентских запросов и ответов сервера. Одна транзакция может использовать более одной базы данных, осуществляя операции чтения и записи во многих базах данных в процессе решения задачи. Задачи, создающие базы данных или изменяющие их физическую структуру (одиночный оператор DDL или пакет таких операторов), также используют транзакции. Клиент и сервер имеют свои роли.

* Роль клиента: клиенты инициируют все транзакции. Когда запущена транзакция, клиент ответственен за передачу запросов на чтение и запись данных, а также за завершение (подтверждение или откат) каждой запущенной им транзакции.

Одно клиентское соединение может иметь много активных транзакций.

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

соответствующим образом обрабатывались конфликты и предотвращалось нарушение согласованности базы данных.

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

Рис. 25.1. Контекст транзакции и независимость

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

Атомарность модели

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

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

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

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

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

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