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

#define isc_dsql_relation_err 335544580L <- an SQLCODE -204 error

Большинство из существующих языков высокого уровня и интерфейсов сценариев уже имеют транслированные объявления констант. Если вам нужна трансляция, рекомендуется обратиться к спискам поддержки. Полный список кодов SQLCODE, GDSCODE и стандартных сообщений на английском языке находится в приложении 10. Использование этих кодов ошибок и расширений языка в PSQL является темой главы 32.

Транзакции для нескольких баз данных

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

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

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

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

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

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

Зависшие транзакции

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

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

Восстановление

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

! ! !

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

. ! .

Ограниченные базы данных

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

Пессимистическая блокировка

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

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