Нарвался на lock conflict при попытке выполнить запрос UPDATE. Начал анализировать код, но, вроде бы, нет одновременно выполняющихся транзакций. Новая стартует не раньше, чем будет выполнен COMMIT или ROLLBACK для предыдущей. Да к тому же блокировка возникает не всегда, а лишь иногда.

Сумасшедшее предположение: приложение отработало слишком быстро, а сервер FB тормознул. В результате на сервер приходит команда на старт новой транзакции, когда предыдущая еще не завершилась. Имеем две различные транзакции, что делает возможным лок конфликт. Может такое быть? Если да, то есть ли культурный способ борьбы с этим безобразием, кроме как вставить что-нибудь типа Sleep(5000) перед StartTransaction?

[+]
Опечатка в заголовке темы: конечно же речь идет о dbExpress

Тогда, наверное, вопросы по dbExpress

1. В приложении есть три TTransactionDesc, но TSQLConnection.InTransaction есть ли вообще активная транзакция. Можно ли узнать, какая именно транзакция стартовала? Можно ли узнать, что активны одновременно более одной транзакции? Если есть возможность как-то увязать их с TRANSACTION_ID в Firebird, то вообще замечательно.

2. Создается экземпляр TSQLQuery, в него загоняется запрос, выполняется и уничтожается. И все это без явного старта транзакции. Если имеется активная транзакция, то запрос выполнится в ней. А если активной транзакции нет, тогда как? Автоматически стартует новая транзакция? А когда она завершится? А если активных транзакций несколько, то в какой выполнится этот запрос? В транзакции с максимальным ID?

автортрейс всё покажет
Если можно, чуть побольше про то, что такое "трейс" и с чем его едят. Хотя бы на уровне ключевых слов и ссылок на описание.
Пока все: чем я располагаю, это вставка в приложение различных запросов мониторинга, которые выполняются при возникновении конфликта (с записью результатов в лог): а потом жду: когда у кого-нибудь из пользователей снова возникнет проблемная ситуация.

Вот такой код в Delphi



Добавил для тестирования, что если возникает exception с текстотом "lock conflict on no wait transaction deadlock update conflicts with concurrent update concurrent transaction number is 1633032010", то выполняю вот такой запрос



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

Из личного опыта или из общих соображений может кто-нибудь подсказать, что здесь сделать, чтобы избежать конфликта либо выявить причину го возникновения?

По ссылке сейчас схожу гляну.

qTMP и BConnection определены в DataModule. Значение qTMP.SQLConnection равно BConnection. Задается в design-time.

У меня он выполнялся после ROLLBACK транзакции с неудавшимся запросом UPDATE (вызов вставил в раздел EXCEPTION защищенного блога. Из сообщения об ошибке, кстати, и id транзакции-конкурента получил. Запрос выполнился, приложение и адрес в лог попали. Приложение мое. Поэтому и говорю так уверенно.

Сейчас рассматриваю вариант перед выполнением запроса UPDATE проверять количество транзакций в mon$trancactions по моему аттачменту. Больше ничего в голову не приходит.

-- Ватсон, это был математик.
-- Почему вы твак решили, Холмс?!
-- Ватсон, это же элементарно! Он подумал прежде, чем ответить. Его ответ абсолютно правильный. Его ответ совершенно бесполезный.
:)

Про причину мне сказал сервер Firebird (только на инглише). А то, что для избегания неприятных последствий, нужно устранить причину -- очевидно.

Мне же интересно, что делать дальше. Ошибка не систематическая. Возникает достаточно редко. Так что даже не знаю, как мне поможет упомянутая выше трассировка. Я же не могу сидеть на всех компьютерах заказчика месяц в ожидании, когда возникнет ошибка. По сути, у меня есть только мое приложение и его лог-файл. Соответственно, мне нужно либо сделать более безопасный код (как-то проверять наличие другой транзакции перед запуском апдейта, либо сбрасывать в лог какую-то дополнительную информацию, которая позволит мне определить, что же это за транзакция осталась болтаться, и почему она осталась болтаться.

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

И я бы рад бы, но.... Есть альтернативы? Повторяю, ошибка не систематическая, возникает редко. Анализировать код на 100 тыс. строк (который дорабатывали 10 программистов на протяжении 15 лет) в поисках возможных причин возникновения такой ситуации -- это нереально. Вот и ищу способ как выкрутиться.

Опять общие слова, что лучше быть богатым и здоровым, чем бедным и больным.
Я и обращаюсь с просьбой, чтобы с высоты собственного опыта подсказали мне, как именно мне поступить, чтобы локализовать причину или сделать код более безопасным.

А про 9 лет... По моему, можно только порадоваться, что в чужих приложениях, которые я поддерживаю, проблемы, с которыми я не могу справиться, возникают раз в 9 лет. В моих собственных приложениях у меня не возникает проблем, с которыми приходилось бы обращаться на форум.

Странно. Я, вроде, описал ситуацию. Трассировка не прокатывает, потому что ошибка не систематическая и возникает редко. Аудит, скорее всего, тоже не получится: не допустит заказчик до своих серверов. Ситуацию я вам обрисовал: и как код на Delphi выглядит, и сообщение об ошибке, и как я определил, что блокирующая транзакция в моем же приложении. Представьте, что задача по поиску этой проблемы вам выдал ваш начальник. Что будете делать? Расказывать ему о том, что такое блокировки, почему они возникают, и что нужно в коде аккуратно обрабатывать конфликты? Пока был только один содержательный совет: проанализировать триггеры.

Если в указанных мной условиях (возможны только модификация приложения и запись в лог-файл) нет нормального способа отыскать причину, то так и скажите, что такого способа нет, анализируй свои километры кода в поисках пропущенного завершения транзакции. Или более честный ответ "я такого способа не знаю", хоть это и бьет по самолюбию. Тогда я не буду здесь сидеть, а буду что-то изобретать... или даже анализировать километры кода. Пойду вставлять запросы к таблицам мониторинга запросы к mon$transactions и mon$statements, может там что-то нарою, что поможет выявить причину ошибки.


Спасибо. Все просто и понятно. Для данной проблемы мне это не поможет, но когда потребуется, буду знать, где посмотреть.

Ошибка возникает при попытке выполнить запрос UPDATE. Я даже знаю строку, в которой это произошло. И даже знаю причину, почему это произошло. Есть большой и ветвистый код на Delphi с большим количеством подпрограмм, который постоянно что-то вычисляет, определяет, меняет... и все это записывает в таблицу либо посредством запросов UPDATE, либо -- SELECT FROM STORED_PROC. Вроде как все эти изменения вносятся в явно стартующих транзакциях, которые сразу же (ну, или почти сразу) завершаются. Где и почему оказалась незавершенная транзакция, я понять не могу. Поэтому даже подумал было сначала, что COMMIT на сервере может выполняться асинхронно, то есть мы команду COMMIT послали и продолжили выполнение кода, а сервер из-за нагрузки тормознул и не успел сразу эту транзакцию завершить. Но мне сказали, что так не бывает. Значит где-то как-то возникло условие, при котором выполнение программы прошло по такому пути, что обошло завершение транзакции. И мне это надо найти. Вот и пытаюсь каким-то образом угадать, где именно. Хотя бы узнать, какой именно запрос изменил запись, а транзакция осталась незавершенной. Как вариант, определить перед проблемным UPDATE, что транзакция уже имеется, и не стартовать новую, а выполнить в существующей. Но тут надо аккуратно все проанализировать, чтобы не напороться на какие-нибудь другие грабли.

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