Что такое 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