Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
Возможность осуществлять явную пессимистическую блокировку строки была добавлена в синтаксис SQL-оператора SELECT в Firebird 1.5. Блокировка ограничена "внешним уровнем" операторов SELECT, которые возвращают выходные наборы или определяют курсоры. Она не может применяться к подзапросам.
Сокращенный синтаксис запроса явной пессимистической блокировки строки:
SELECT <выходной-список>
FROM <таблица-или-процедура-или-просмотр>
[WHERE <условия-поиска>]
[GROUP BY <спецификация-группирования>]
[UNION <выражение-выбора> [ALL]]
[PLAN <выражение-плана>]
[ORDER BY <список-столбцов>]
[FOR UPDATE [OF
Предложение FOR UPDATE, не являющееся инструкцией блокировки, указывает, что выходной набор должен передаваться клиенту по одной строке за раз, а не в виде пакета. Необязательная фраза WITH LOCK является элементом, который задает предварительную блокировку строки, как только сервер передает ее с сервера. Строки, ожидающие вывода, не блокируются.
Традиционным способом получения пессимистической блокировки строки в Firebird являются фиктивные изменения (dummy updates). Этот трюк позволяет использовать преимущества многоверсионной архитектуры. Клиент просто посылает на сервер для строки оператор изменения, который ничего не изменяет - он просто устанавливает значение столбца в его текущее значение, что приводит к тому, что сервер создает новую версию записи и, следовательно, блокирует для других транзакций запрос на изменение или удаление этой строки.
Условия, при которых пессимистическая блокировка может быть полезной, и технические рекомендации по ее использованию обсуждаются в главе 27.
Конфликты блокировки
Конфликт блокировки появляется, когда конкурирующие транзакции пытаются изменить или удалить одну и ту же строку в то время, когда вид состояния базы данных для этих транзакций частично перекрывается. Конфликты блокировок являются запланированным результатом уровней изоляции транзакций в Firebird и стратегии поддержания многих версий записи, защищая изменяемые данные от неконтролируемой перезаписи параллельными операциями над одними и теми же данными.
Эта стратегия работает хорошо только в случае двух условий, которые приводят к конфликтам блокировки.
* Условие 1: одна транзакция (наша транзакция) отправила на сервер изменение или удаление строки. В это время другая транзакция, стартовавшая до того, как наша транзакция заблокировала эту строку, пытается ее изменить или удалить. Другая транзакция получает конфликт блокировки и имеет два варианта выбора:
• она может отменить свою попытку и позже снова повторить ее для вновь подтвержденной версии строки;
• она может ждать, пока наша транзакция либо подтвердит, либо отменит свою работу.
* Условие 2: наша транзакция блокирует для записи целую таблицу, если имеет уровень изоляции для таблицы SNAPSHOT TABLE STABILITY или использует резервирование таблицы с помощью PROTECTED, а другая транзакция пытается изменить или удалить строку или добавить новую строку.
Предположим, что наша транзакция
Если наша транзакция подтверждает изменения, то другая транзакция получит отказ по конфликту изменения. Клиент, который запустил другую транзакцию, должен иметь обработчик исключений, который либо откатит транзакцию и заново ее запустит для повторной выдачи запроса, либо просто подтвердит транзакцию и завершит работу.
Вызов COMMIT в обработчике исключения конфликта блокировки не рекомендуется, поскольку он разрушает атомарность транзакции - некоторая работа будет завершена, некоторая нет, и впоследствии будет невозможно предсказать состояние базы данных [97] .
97
Ничто не запрещает завершить транзакцию по COMMIT, независимо от успеха или неуспеха выполнения в ней операторов. Разумеется, именно в обработчиках исключений вызывать COMMIT действительно не рекомендуется.
– Прим. науч. ред.
К сожалению, Firebird имеет тенденцию объединять все исключения блокировки и сообщает о них как "deadlock" (взаимная блокировка). Нормальные случаи, которые были описаны, не являются взаимной блокировкой.
Что такое взаимная блокировка?
Взаимная блокировка является просто сокращенным названием, заимствованным из реслинга, для условия, когда две транзакции борются за изменение строк в перекрывающихся наборах и ни одна транзакция не имеет приоритета перед другой.
Например, наша транзакция имеет изменения, ожидающие завершения, для строки x и собирается изменять строку Y в то время, как другая транзакция имеет изменения, ожидающие завершения, для строки Y и собирается изменять строку x, и обе транзакции имеют режим WAIT. Как и в реслинге, взаимная блокировка может быть разрешена, только если один из борцов не удержит руку. Одна транзакция должна выполнить откат, чтобы позволить другой подтвердить свои изменения.
Firebird предоставляет приложениям средство разрешения взаимной блокировки путем сканирования блокировок каждые несколько секунд. Он произвольно выберет одну из транзакций -взаимной блокировки и выдаст для нее исключение взаимной блокировки.
Разработчики не должны бояться сообщений о взаимной блокировке. Наоборот, имеет смысл изолировать работу многих пользователей в контекстах транзакций. Вы должны допускать наличие взаимных блокировок и эффективно их обрабатывать в вашем приложении.
Если наша транзакция выбрана для разрешения взаимной блокировки, обработчик исключения в приложении должен выполнить откат транзакции, чтобы позволить другой транзакции возобновить и завершить свою работу. Альтернатива - подтверждение транзакции в обработчике исключения - не рекомендуется, поскольку наша транзакция станет неатомарной, а другая транзакция даст сбой по конфликту блокировки.