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

Второй уровень, GDSCODE, предоставляет гораздо больше возможностей определения исключений. Каждый код GDSCODE является знаковым целым, константы которого представлены в iberror.h (или в interbase.msg, если вы используете версию 1.0.x)[105]. Как правило, сообщение GDSCODE достаточно точно указывает, что произошло[106]. В Firebird 1.5 значительно улучшена информация, передаваемая в сообщениях. Тем не менее GDSCODE предоставляет для приложений наиболее полезный механизм диагностики; вы можете преобразовать константы в пользовательские сообщения в вашем модуле на включающем языке для использования в обработчиках исключений.

В следующем примере приложение делает попытку добавить данные в таблицу, которая не существует:

INSERT INTO NON_EXISTENT (TEST)

VALUES ('ABCDEF');

Следующая информация об ошибке возвращается приложению (утилита администратора IB SQL в этом случае):

ISC ERROR CODE:335544569 <- GDSCODE

Dynamic SQL Error <- corresponding text from firebird.msg

SQL error code = -204 <- SQLCODE

Table unknown <- corresponding text from firebird,msg

NON_EXI STENT

Откуда приложение получает коды ошибок и сообщения? Ответ можно найти в векторе состояния ошибки (error status vector), в массиве, который передается в качестве параметра в большинство функций API. Эти функции возвращают состояние и коды ошибок клиенту вместе с соответствующими строками из файла сообщений Firebird[107]. API также предоставляет клиентским приложениям служебные функции для чтения содержимого векторов состояния ошибок в локальных буферах. Обработчики ошибок могут затем анализировать содержимое этих буферов и использовать полученную информацию для принятия решения, как поступить с исключением, а также выдать пользователю дружественное сообщение.

Заголовочный файл iberror.h в вашем каталоге /include содержит объявления, каждое из которых связано с SQLCODE и GDSCODE через символическую константу. Например, вот объявления констант для двух кодов ошибок из предыдущего примера:

. . .

#define isc_dsql_error 335544569L

. . .

#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 все изменения выполняются на уровне строки - не существует механизма блокировки отдельного столбца. Почти на всех уровнях изоляции транзакции ядро сервера осуществляет принцип оптимистической блокировки: все транзакции, не ограниченные какой-либо формой пессимистической блокировки, начинаются с просмотра текущего подтвержденного состояния всех строк во всех таблицах- конечно, при соответствующих привилегиях. Когда транзакция передает запрос на изменение строки, старая версия этой строки остается видимой всем транзакциям. Писатели не блокируют читателей.

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

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

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

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

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

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

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

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

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

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