Что такое deadlock и как с ним бороться?

Начнем с того, что буквальный перевод слова deadlock означает "мертвая блокировка". При работе с BDE (Delphi, C++Builder, ...) с клиентской части и в IB Database с триггерами и хранимыми процедурами мы имеем два случа появления сообщения deadlock - при чтении и при обновлении. До действительно "мертвого" блокирования дело не доходит, поскольку IB SQL Link стартует любую транзакцию с параметром NO WAIT (т.е. не ожидать разрешения конфликта).

Deadlock при обновлении

Две транзакции, еще не завершившиеся, но пытающиеся обновить одни и те-же записи, считаются конкурирующими. Существует два режима обработки deadlock - wait и no wait (с ожиданием и без ожидания). В BDE для любых транзакций IB используется режим без ожидания, и режим с ожиданием можно установить только при прямой работе с IB API (например через FreeIBComponents).

"Неудачливой", естественно, считается транзакция, получившая сообщение о deadlock. Это означает, что одно из действий, проводимых в транзакции, не может быть выполнено. Следовательно, такая транзакция должна быть отменена (rollback). Следует избегать длительных транзакций, которые могут попасть в такую ситуацию - единственным выходом из нее будет попытка начать транзакцию снова и повторить все действия.

Уменьшить число возможных конфликтов обновления можно сократив врем выполнения транзакции. Например, сначала принимаются данные от пользователя, и если он подтверждает введенную информацию, приложение стартует транзакцию, быстро передает данные на сервер, и завершается. Чем быстрее пройдет транзакция, тем больше у нее шансов завершиться успешно. Именно для этого в BDE 3.x был введен режим Cached Updates (кэшированные изменения). При Cached Updates изменения накапливаются на клиентской части приложения, затем при вызове метода ApplyUpdates изменения "выстреливаются" на сервер. В любом случае, даже если вы не можете избавиться от длительных обновляющих транзакций, нужно продумать логику приложения и обязательно предусматривать в приложении обработку возникающих конфликтов.

Deadlock при чтении

Все описываемые ниже проблемы исправлены в BDE 4.01. При этом параметр DRIVER FLAGS указывать не нужно.

Deadlock при чтении возникает в основном в SQL-серверах, которые используют страничные блокировки при чтении или модификации данных (MS SQL и Sybase). Кажется странным, что при работе с IB, в котором блокировки вообще отсутствуют (конфликт обновления блокировкой не считается - это не блокировка а именно конфликт), иногда все-таки возникает deadlock при чтении данных.

Причина вот в чем: транзакции уровня изоляции Read Committed имеют в IB два режима - NO RECORD VERSION и RECORD VERSION. В первом случае, если при чтении записи ядро IB обнаруживает наличие неподтвержденной (uncommitted) версии этой записи, то возвращает сообщение о deadlock. Это как-бы сигнализирует приложению, что скоро эта запись возможно будет обновлена (ведь в ReadCommitted чужие изменения будут видны сразу после их подтверждения (commit)). В режиме RECORD VERSION наличие неподтвержденных версий записей игнорируется, и всегда возвращается старая версия записи.

Казалось-бы, так почему-бы BDE не работать по умолчанию в режиме RECORD VERSION ? К сожалению, так изначально было заложено - транзакция Read Committed в BDE запускается с параметром NO RECORD VERSION - но до версии Delphi 2.0 этого неудобства почти никто не заметил. А вот почему не заметили, читаем дальше.

Уровень изоляции в AUTOCOMMIT в разных версиях BDE

В зависимости от версии BDE менялись уровни изоляции по умолчанию. Когда вы явно не используете методы управления транзакциями (Database.StartTransaction, Commit и Rollback), то за вас это делает BDE. Не верите ? Посмотрите в SQL Monitor. Самое главное, что тип транзакции по умолчанию "зашит" в SQL Link. И даже если вы поместили на форму компонент TDatabase, и изменили у него свойство tiTransIsolation, то это не влияет на BDE, пока вы не вызовете метод Database.StartTransaction.

Итак, какие-же транзакции стартует по умолчанию BDE ?

Delphi 1.0, BDE 2.52 - Repeatable Read
Delphi 2.0, BDE 3.x - Read Committed
Delphi 3.0, BDE 4.0 - Read Committed
Delphi 3.01, BDE 4.01, 4.51 - Read Committed с параметром RECORD VERSION - deadlock-и при чтении отсутствуют.

Итак, deadlock-и при чтении заметили только в Delphi 2.0, именно потому что транзакция по умолчанию сменилась на Read Committed. Кстати, в READLINK.TXT для Delphi 2.x и 3.0 написано, что если нужно изменить транзакцию по умолчанию на Repeatable Read, то следует установить в параметрах драйвера DRIVER FLAGS = 512. Т.е. фактически "обеспечить совместимость" поведени приложений, перенесенных в Delphi 2 из Delphi 1.

! Не устанавливайте DRIVER FLAGS не прочитав предварительно READLINK.TXT. Дело в том, что например в версии 4.0 количество флагов увеличилось:

0 Read Committed, немедленное подтверждение любых изменений (может вызвать перечитывание курсоров TQuery)
512 Repeatable Read, немедленное подтверждение любых изменений (может вызвать перечитывание курсоров TQuery)
4096 Read committed, подтверждение изменений выполняется как COMMIT RETAIN, сохраняя контекст курсоров TQuery
4608 Repeatable read, подтверждение изменений выполняется как COMMIT RETAIN, сохраняя контекст курсоров TQuery