post invoice Batch - multithread

[alicedr]

CU13, 3 batch servers
Есть батч, который постит инвойсы/разносит накладные.
Во время разноски накладной происходит отправка неких данных и отправляться они могут только один раз. Если во время отправки, или после, возникают ошибки, накладная не разносится, хотя данные уже отправлены. При повторной отправке данных возникает ошибка и накладная не разносится.

Было замечено, что для некоторых накладных отправка происходит несколько раз.
Для отладки был добавлен вывод в infolog ключевых параметров отправляемых данных в виде "транзакция № была отправлена, накл №, сумма ххх, текущее время хх.хх.хх" + эту же информацию вместе со стек трейсом стали записывать в отдельную таблицу с помощью отдельного соединения.

Анализ логов батчей показал, что накладные разделялись на потоки по номерам, в порядке возрастания, как и положено. Данные о транзакции в инфологе видно только в логе одного потока под номером соотв. накладной.
Но в новой таблице логов видно, что транзакции отправлялись несколько раз, иногда до 8 раз!.Попытки найти в логе батча данные об остальных транзакциях с нужным временем не увенчались успехом.

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

Вопрос следующий: почему запускается отправка нелегальных транзакций и как отловить их лог?

[Stitch_MS]

Вам, скорее всего, нужно не отлавливать нелегальные транзакции, а писать отправляемые данные в отдельную новую таблицу, и отправлять их отдельным процессом уже оттуда. Ваши «нелегальные» транзакции – это вполне обычные при параллельной обработке конфликты обновления записей, которые успешно разрешаются штатно.

[alicedr]

Мои данные это платеж по накладной с помощью кредитной карты и производиться он должен во время разноски накладной. Платеж успешен-накланая разнесена и наоборот. Разделять процессы нельзя по условию.

[alicedr]

Цитата:

Сообщение от Stitch_MS

Ваши «нелегальные» транзакции – это вполне обычные при параллельной обработке конфликты обновления записей, которые успешно разрешаются штатно.

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

[fed]

Цитата:

Сообщение от alicedr

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

А вы не пробовали лог батча обновлять через параллельное соединение к БД (Класс connection)? (Как это с номерными сериями сделано в стандарте). Просто если вы лог обновляете в основном соединении, то при откате транзакции (из за ошибок или из за повторяющихся конфликтов обновления), у вас не только сама транзакция откатится, но и ваш лог...

[alicedr]

Цитата:

Сообщение от fed

А вы не пробовали лог батча обновлять через параллельное соединение к БД (Класс connection)? (Как это с номерными сериями сделано в стандарте). Просто если вы лог обновляете в основном соединении, то при откате транзакции (из за ошибок или из за повторяющихся конфликтов обновления), у вас не только сама транзакция откатится, но и ваш лог...

Дык батч-то стандартный...

[alicedr]

Причиной многократных попыток запустить на обработку одну и ту же накладную оказался стандартный FormLetterService.run(), который при exceptioneadlock удаляет из лога данные о транзакции и запускает все по-новой.

Deadlock происходит на апдейте MCRCustPaymTable и происходит это только во время выполнения батча, когда запускаются все накладные за день в несколько потоков. Запуск нескольких накладных в батче проходит без изъянов, роль играет явно количество.

SQL 2014, флаг 1224 для lock escalation включен.
В trace parser получилось найти только один из двух запросов из дедлока.
В trace parser'e также получилось идентифицировать, что сообщение об ошибке было следующее:

Deadlock, where one or more users have simultaneously locked the whole table or part of it