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

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

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

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

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

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

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

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

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

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

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

Блокировка на уровне оператора

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

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

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

Для случаев, когда необходима пессимистическая блокировка на уровне строки, механизм пессимистической блокировки и поддерживаемый синтаксис SQL реализованы в версии 1.5. До этого сервер Firebird по существу этого не поддерживал. В данном разделе мы сначала посмотрим на стандартный "трюк", который выполняют клиентские приложения- когда для этого отсутствует языковая поддержка для получения пессимистической блокировки. Затем мы рассмотрим синтаксис и условия явного SELECT ... WITH LOCK, который осуществляет поддержку пессимистической блокировки для SQL в Firebird 1.5.

Трюк "фиктивное изменение"

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

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

UPDATE ATABLE

SET PKEY = PKEY

WHERE PKEY = PKEY;