Знатоки, будьте добры, подскажите по матчасти. Имеются два клиентских приложения на Delphi (на фибплюсах), которые одновременно могут делать insert/update/delete в одни и те таблицы. С недавних пор начал возникать lock conflict on no wait transaction (concurrent update).

Итак, вопросы:

1. Обязательна ли транзакция при update в таблицу (trModifyDoc - FibTransaction)?




Довольно давно уже в одном приложении убрал вообще транзакцию



Теперь вот думаю - не последствия ли этого проявляются deadlock-ом

2. Если транзакия необязательна, то простой update без транзакции вида


может вызвать deadlock?
Грубо говоря, нужно понимание - как лучше сделать - навесить транзакций на любой апдейт в таблицу
или же наоборот убрать все транзакции на апдейты в некритичные таблицы (инфа в которых производна и может обновиться потом на основе критичных таблиц при запуске приложения), которые тем не менее могут вызвать deadlock, который в свою очередьмаксимально критичен в одном из приложений (кассовом)

3. Как влияют друг на друга вложенные транзакции, висящии на разных компонентах FibTransaction
Скажем




Каждый FibTransaction отвечает за отдельный update в разные таблицы.
Но таблицы разные только в рамках одного приложения.
Во втором приложении идут такие же вложенные транзакции в же таблицы, что и в первом приложении

Не лучше ли сделать одну общую транзакцию для одного приложения и также одну общую на все апдейты для второго?
Или же этого ничего не даст в плане борьбы с deadlock-ами?

Да еще такой вопрос - как лучше - для каждого FibQuery создавать отдельную FibTransaction
или все Query скажем на апдейт вешать на один FibTransaction
То есть Query1 -> trModifyDoc1, Query2 -> trModifyDoc2, Query3 -> trModifyDoc3
или же
Query1 -> trModifyDoc1, Query2 -> trModifyDoc1, Query3 -> trModifyDoc1

Благодарю за помощь! И наконец еще такой вопрос - имеет смысл логику транзакций перевесить с клиента на триггеры в самой БД? Ну то есть к примеру убираю запрос
и вместо него вешаю триггер на AfterInsert в основной таблице - это поможет избежать deadlock-ов или вообще без разницы?

Насчет логики - не буду спорить, почти все было сделано до меня, сейчас приходится надстраивать относительно текущих реалий
Есть две таблицы journaldoc - таблица приходных и расходных доков (чеков, итд) и tabledoc - строк этих доков. На уровне БД целостность не контролируется. Приходники соответственно со знаком +, расходники -
При этом возможная проблема была изначально в том, что в tabledoc строки сворачиваются. То есть грубо говоря пришло 4 упаковки одинакового товара (id_tovara, id_proizv, id_serii, cena) - они будут все идти одной строкой, где kolvo = 4
И продажи раньше также шли одной строкой до внедрения онлайн касс и требования слать в ОФД каждую позицию. С тех пор позиции чека пишутся в tabledoc построчно.

Но с недавних ввели маркировку и приход тоже по уму надо бы делать построчно, чтобы каждую марку отсканированную писать в отдельную строку. Но тут уже так просто как с продажами не прокатит - очень много кода надо переписывать
Поэтому добавил еще одну таблицу для хранения кодов маркировки - datamatrixes. Это похоже и вызвало рост дэдлоков - они и раньше были но пару раз за год и в программе, где проводится приход, то есть там где некритично. А сейчас уже пару раз было в кассовой проге - а это уже критично, из-за дэдлока происходило "слипание" двух чеков в один. Это уже другая проблему - тут надо разбираться грубо говоря что можно сделать с обработкой результата дэдлока, чтобы такого не было. Но вообще хотелось бы не обратывать дэдлок, а искоренить эту проблему на корню

Как я понимаю сейчас происходит дэдлок именно на datamatrixes (жалко что FB не показывает имя таблицы в ошибке).
Так как сейчас при пробитии чека идет update datamatrixes в кассовой проге и одновременно может быть insert into datamatrixes в складской проге. Но опять таки очень странно как так получается, потому что один и тот же набор данных никак не должен обрабатываться, так как сам datamatrix - это уникальный ключ, которые на может повторяться - даже на уровне сканирования сделал удаление дублей, если случайно 2 раза одно и то же отсканируют. То есть по идее не может быть вообще одновременного обращения к одной и той же записи таблицы datamatrixes, но deadlock тем не менее есть

Кстати кроме дэдлока еще возникла неприятная проблема - на некоторых точках (не везде) начались взаимные подвешивания обоих прог (касовой и складской). в момент активного приема товара в складской - но уже без дэдлока. Тут не могу понять в чем. Может concurrent update вызывать такое подвисание - 5, 10 , 20 минут? Либо же проблема в том, что при выводе некоторых форм используется циклы while not true и всякие события, логика которых возможно нарушилась с внесением изменений по маркировке

Господа, в продолжении темы. Решил идти по пути - убрать все апдейты, а необходимые делиты из таблицы текущих остатков датаматриксов делать раз в сутки по событию. Сейчас споткнулся о вот такой запрос - выполняется 15 ms - что недопустимо много, учитывая что в CurDataM всего 5 тысяч записей. Подскажите как оптимизировать? Сразу выбирать не получится, так как сначала надо определить sgtin-ы и потом уже по каждому минимальное кол-во. Значения сразу подставил, но в реале они подставляютя праметрами в цикле по строкам документа. А строк может и 100. Так что по 15 ms на 2 записи - что-то дохрена


План запроса на скрине

Dimitry Sibiryakov, так просто не убрать. В подзапросе нет нужных записей. Поэтому приходится подзапросом определять нужные sgtin-ы и потом уже новым select-ом по всей таблице искать нужные записи по sgtin с мин. кол-вом. Можно конечно попробовать join-ом, но не уверен будет ли быстрее. Интересно есть еще какие-нибудь конструкции чтобы максимально ускорить join таблицы с самой собой

hvlad, так точно, создал, взлетело