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

* Условие 1: одна транзакция (наша транзакция) отправила на сервер изменение или удаление строки. В это время другая транзакция, стартовавшая до того, как наша транзакция заблокировала эту строку, пытается ее изменить или удалить. Другая транзакция получает конфликт блокировки и имеет два варианта выбора:

• она может отменить свою попытку и позже снова повторить ее для вновь подтвержденной версии строки;

• она может ждать, пока наша транзакция либо подтвердит, либо отменит свою работу.

* Условие 2: наша транзакция блокирует для записи целую таблицу, если имеет уровень изоляции для таблицы SNAPSHOT TABLE STABILITY или использует резервирование таблицы с помощью PROTECTED, а другая транзакция пытается изменить или удалить строку или добавить новую строку.

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

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

Вызов COMMIT в обработчике исключения конфликта блокировки не рекомендуется, поскольку он разрушает атомарность транзакции - некоторая работа будет завершена, некоторая нет, и впоследствии будет невозможно предсказать состояние базы данных [97] .

К сожалению, Firebird имеет тенденцию объединять все исключения блокировки и сообщает о них как "deadlock" (взаимная блокировка). Нормальные случаи, которые были описаны, не являются взаимной блокировкой.

Взаимная блокировка является просто сокращенным названием, заимствованным из реслинга, для условия, когда две транзакции борются за изменение строк в перекрывающихся наборах и ни одна транзакция не имеет приоритета перед другой.

Например, наша транзакция имеет изменения, ожидающие завершения, для строки x и собирается изменять строку Y в то время, как другая транзакция имеет изменения, ожидающие завершения, для строки Y и собирается изменять строку x, и обе транзакции имеют режим WAIT. Как и в реслинге, взаимная блокировка может быть разрешена, только если один из борцов не удержит руку. Одна транзакция должна выполнить откат, чтобы позволить другой подтвердить свои изменения.

Firebird предоставляет приложениям средство разрешения взаимной блокировки путем сканирования блокировок каждые несколько секунд. Он произвольно выберет одну из транзакций -взаимной блокировки и выдаст для нее исключение взаимной блокировки.

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

Если наша транзакция выбрана для разрешения взаимной блокировки, обработчик исключения в приложении должен выполнить откат транзакции, чтобы позволить другой транзакции возобновить и завершить свою работу. Альтернатива - подтверждение транзакции в обработчике исключения - не рекомендуется, поскольку наша транзакция станет неатомарной, а другая транзакция даст сбой по конфликту блокировки.

В редких случаях более двух транзакций может быть включено во взаимную блокировку при борьбе за перекрывающиеся наборы. Иногда это называется тупиковой ситуацией (программистский жаргон - deadly embrace, смертельные объятия). Сканирование блокировок выберет одну транзакцию (нашу транзакцию), ситуация будет обработана в клиентском обработчике исключений, как в предыдущем примере. При этом даже если клиент выполнит откат нашей транзакции, те другие транзакции все еще останутся заблокированными.

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