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

Кузьменко Дмитрий, Epsylon Technologies

Начнем с того, что буквальный перевод слова 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 при чтении

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.
  Дело в том, что, например, в версии 4.0 количество флагов увеличилось:

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