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

SELECT * FROM ATABLE

FOR UPDATE WITH LOCK;

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

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

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

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

Идентификаторы транзакций и ассоциированные с ними состояния данных сохраняются в инвентарных страницах транзакций. На заголовочной странице базы данных система учета поддерживает набор полей, содержащих идентификаторы транзакций, интересующих эту систему, а именно старейшую заинтересованную транзакцию (Oldest Interesting Transaction, OIT), старейшую активную транзакцию (Oldest Active Transaction, OAT) и число, используемое в следующей транзакции. "Мгновенный снимок" идентификатора транзакции также записывается каждый раз, когда увеличивается OAT - обычно тот же самый идентификатор, что и OAT, или близкий к нему.

Firebird 1.5 и более поздние версии имеют контекстную переменную CURRENT? TRANSACTION, которая возвращает идентификатор данной транзакции. Она может использоваться в SQL в любом выражении. Например, для сохранения идентификатора транзакции в таблице протокола вы можете использовать следующее:

INSERT INTO BOOK_OF_LIFE

(TID, COMMENT, SIGNATURE) VALUES

(CURRENT_TRANSACTION,

'This has been a great day for transactions', CUERENT_USER) ;

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

Как было сказано, идентификатор транзакции является 32-битовым целым. Если последовательность идентификаторов превысит лимит в 4 Гбайт и начнется новый отсчет, то могут произойти неприятные вещи. Когда завершится последняя транзакция, системная транзакция перестанет работать, и изменение метаданных будет невозможным. Сборка мусора прекратится. Транзакции пользователя не станут запускаться.

При 100 транзакциях в секунду это займет 1 год, 4 месяца, 11 дней, 2 часа и приблизительно 30 минут [90] .

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

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

Активные, зависшие (limbo), отмененные и "умершие" транзакции все являются интересными. Транзакции, которые были подтверждены с использованием оператора COMMIT WITH RETAIN (мягкое подтверждение или CommitRetaining), остаются активными, пока не будут подтверждены жестко, и поэтому являются интересными. В некоторых случаях интересные транзакции могут стать "застрявшими" и станут тормозить работу.

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