Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Firebird поддерживает операции над несколькими базами данных под управлением одной транзакции. Он автоматически реализует двухфазное подтверждение (Two- Phase Commit, 2РС), чтобы гарантировать, что транзакция не подтвердит работу в одной базе данных, пока не будет возможности подтвердить работу в других базах данных. Данные никогда не будут частично подтвержденными.

На первой фазе двухфазного подтверждения или отката Firebird подготавливает к подтверждению (или откату) работу в каждой базе данных, разделяя транзакцию на

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

* Если это операция подтверждения и какая-нибудь подтранзакция не может быть подтверждена, возникает исключение. Все подтранзакции, отмеченные для подтверждения, переводятся в "переходное" состояние, а состояние базы данных не изменяется ни при каких условиях.

* Если подтверждение везде выполнилось успешно, то все подтранзакции переводятся в состояние "подтвержденные", а изменения базы данных становятся постоянными.

* Если это операция отката, то подтранзакции переводятся в состояние отмены.

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

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

Пока зависшая транзакция не будет завершена (подтверждена или отменена), она остается "заинтересованной" в Firebird, который сохраняет статистику по незавершенным транзакциям. Восстановление зависшей транзакции означает ее подтверждение или отмену. Утилита gfix может восстановить зависшие транзакции и позволяет вам взаимодействовать с ними интерактивно. Более подробную информацию см. в главе 39.

! ! !

Примечание. В базах данных, с которыми работают с помощью драйверов, не использующих двухвфазное подтверждение, таких как Borland Database Engine (BDE), никогда не возникает зависших транзакций.

. ! .

Транзакции над несколькими базами данных могут использовать много ресурсов сервера. В ESQL Firebird предоставляет языковую поддержку в форме предложения USING для ограничения баз данных, к которым транзакциям разрешен доступ. DSQL не предоставляет языковую поддержку. Интерфейсы DSQL могут использовать структуры API в блоке параметров транзакции для ограничения транзакций с множеством баз данных различными способами. Некоторые классы компонентов доступа к данным предоставляют доступ к этим режимам через свойства.

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

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

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

Firebird разработан для интерактивного использования многими конкурирующими пользователями; редко можно найти подлинные причины для использования пессимистической блокировки. Это не "магическая пуля", с помощью которой нужно эмулировать поведение настольных СУБД. Пессимистические блокировки одной транзакции приведут к конфликтам в других транзакциях. Нет возможности уйти от ответственности при работе с многопользовательской моделью транзакций и написании обработчиков предполагаемых конфликтов блокировки.

Уровень изоляции транзакции TABLE STABILITY (или согласованная изоляция) предоставляет полную блокировку таблицы по записи, включая зависимые таблицы. Этот уровень слишком агрессивен для интерактивных приложений.

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

RESERVING <���предложение -резервирования>;

<���предложение-резервирования> = table [, table ...]

[FOR [SHARED f PROTECTED] {READ | WRITE}]

[, <���предложение-резервирования>]

<���предложение-резервирования> может включать в себя множество спецификаций резервирования наборов, предоставляя возможность резервировать различные таблицы или группы таблиц с различными правами. Конкретная таблица должна появляться только один раз в предложении резервирования. Обратитесь к предыдущей главе для получения информации о резервировании таблиц.

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