|
|
09.05.2018, 02:51
|
#1 |
|
Участник
|
post invoice Batch - multithread
CU13, 3 batch servers
Есть батч, который постит инвойсы/разносит накладные. Во время разноски накладной происходит отправка неких данных и отправляться они могут только один раз. Если во время отправки, или после, возникают ошибки, накладная не разносится, хотя данные уже отправлены. При повторной отправке данных возникает ошибка и накладная не разносится. Было замечено, что для некоторых накладных отправка происходит несколько раз. Для отладки был добавлен вывод в infolog ключевых параметров отправляемых данных в виде "транзакция № была отправлена, накл №, сумма ххх, текущее время хх.хх.хх" + эту же информацию вместе со стек трейсом стали записывать в отдельную таблицу с помощью отдельного соединения. Анализ логов батчей показал, что накладные разделялись на потоки по номерам, в порядке возрастания, как и положено. Данные о транзакции в инфологе видно только в логе одного потока под номером соотв. накладной. Но в новой таблице логов видно, что транзакции отправлялись несколько раз, иногда до 8 раз!.Попытки найти в логе батча данные об остальных транзакциях с нужным временем не увенчались успехом. Итого: - в логе батча видно только одну транзакцию (назовем ее легальной) - отправка нелегальных транзакций происходит от того же имени, что и батч - нелегальные транзакции происходят в период выполнения батча - другие батчи в это время не выполнялись - стек трейс для всех транзакций одинаковый, то есть запускается одно и то же. Вопрос следующий: почему запускается отправка нелегальных транзакций и как отловить их лог? |
|
|
|
09.05.2018, 09:21
|
#2 |
|
Участник
|
Вам, скорее всего, нужно не отлавливать нелегальные транзакции, а писать отправляемые данные в отдельную новую таблицу, и отправлять их отдельным процессом уже оттуда. Ваши «нелегальные» транзакции – это вполне обычные при параллельной обработке конфликты обновления записей, которые успешно разрешаются штатно.
|
|
|
|
09.05.2018, 13:24
|
#3 |
|
Участник
|
Мои данные это платеж по накладной с помощью кредитной карты и производиться он должен во время разноски накладной. Платеж успешен-накланая разнесена и наоборот. Разделять процессы нельзя по условию.
|
|
|
|
09.05.2018, 13:28
|
#4 |
|
Участник
|
Цитата:
Сообщение от Stitch_MS
Ваши «нелегальные» транзакции – это вполне обычные при параллельной обработке конфликты обновления записей, которые успешно разрешаются штатно.
|
|
|
|
09.05.2018, 14:26
|
#5 |
|
Moderator
|
Цитата:
Сообщение от alicedr
к сожалению, сейчас это выглядит как многочисленные попытки разнести одну и ту же накладную в одном и том же батче, возможно в разных потоках, при этом в логе батча записывается только одна попытка.
|
|
|
|
09.05.2018, 21:13
|
#6 |
|
Участник
|
Цитата:
Сообщение от fed
А вы не пробовали лог батча обновлять через параллельное соединение к БД (Класс connection)? (Как это с номерными сериями сделано в стандарте). Просто если вы лог обновляете в основном соединении, то при откате транзакции (из за ошибок или из за повторяющихся конфликтов обновления), у вас не только сама транзакция откатится, но и ваш лог...
|
|
|
|
17.05.2018, 02:09
|
#7 |
|
Участник
|
Причиной многократных попыток запустить на обработку одну и ту же накладную оказался стандартный FormLetterService.run(), который при exception
 eadlock удаляет из лога данные о транзакции и запускает все по-новой.Deadlock происходит на апдейте MCRCustPaymTable и происходит это только во время выполнения батча, когда запускаются все накладные за день в несколько потоков. Запуск нескольких накладных в батче проходит без изъянов, роль играет явно количество. SQL 2014, флаг 1224 для lock escalation включен. В trace parser получилось найти только один из двух запросов из дедлока. В trace parser'e также получилось идентифицировать, что сообщение об ошибке было следующее: X++: Deadlock, where one or more users have simultaneously locked the whole table or part of it |
|
|
|
|
|
Комбинированный вид
