AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 09.05.2018, 02:51   #1  
alicedr is offline
alicedr
Участник
 
173 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Канада
post invoice Batch - multithread
CU13, 3 batch servers
Есть батч, который постит инвойсы/разносит накладные.
Во время разноски накладной происходит отправка неких данных и отправляться они могут только один раз. Если во время отправки, или после, возникают ошибки, накладная не разносится, хотя данные уже отправлены. При повторной отправке данных возникает ошибка и накладная не разносится.

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

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

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

Вопрос следующий: почему запускается отправка нелегальных транзакций и как отловить их лог?
Старый 09.05.2018, 09:21   #2  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
396 / 478 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Вам, скорее всего, нужно не отлавливать нелегальные транзакции, а писать отправляемые данные в отдельную новую таблицу, и отправлять их отдельным процессом уже оттуда. Ваши «нелегальные» транзакции – это вполне обычные при параллельной обработке конфликты обновления записей, которые успешно разрешаются штатно.
Старый 09.05.2018, 13:24   #3  
alicedr is offline
alicedr
Участник
 
173 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Канада
Мои данные это платеж по накладной с помощью кредитной карты и производиться он должен во время разноски накладной. Платеж успешен-накланая разнесена и наоборот. Разделять процессы нельзя по условию.
Старый 09.05.2018, 13:28   #4  
alicedr is offline
alicedr
Участник
 
173 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Канада
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Ваши «нелегальные» транзакции – это вполне обычные при параллельной обработке конфликты обновления записей, которые успешно разрешаются штатно.
к сожалению, сейчас это выглядит как многочисленные попытки разнести одну и ту же накладную в одном и том же батче, возможно в разных потоках, при этом в логе батча записывается только одна попытка.
Старый 09.05.2018, 14:26   #5  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от alicedr Посмотреть сообщение
к сожалению, сейчас это выглядит как многочисленные попытки разнести одну и ту же накладную в одном и том же батче, возможно в разных потоках, при этом в логе батча записывается только одна попытка.
А вы не пробовали лог батча обновлять через параллельное соединение к БД (Класс connection)? (Как это с номерными сериями сделано в стандарте). Просто если вы лог обновляете в основном соединении, то при откате транзакции (из за ошибок или из за повторяющихся конфликтов обновления), у вас не только сама транзакция откатится, но и ваш лог...
Старый 09.05.2018, 21:13   #6  
alicedr is offline
alicedr
Участник
 
173 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Канада
Цитата:
Сообщение от fed Посмотреть сообщение
А вы не пробовали лог батча обновлять через параллельное соединение к БД (Класс connection)? (Как это с номерными сериями сделано в стандарте). Просто если вы лог обновляете в основном соединении, то при откате транзакции (из за ошибок или из за повторяющихся конфликтов обновления), у вас не только сама транзакция откатится, но и ваш лог...
Дык батч-то стандартный...
Старый 17.05.2018, 02:09   #7  
alicedr is offline
alicedr
Участник
 
173 / 43 (2) +++
Регистрация: 06.07.2012
Адрес: Канада
Причиной многократных попыток запустить на обработку одну и ту же накладную оказался стандартный FormLetterService.run(), который при exceptioneadlock удаляет из лога данные о транзакции и запускает все по-новой.

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
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
dynamicsax-fico: Vendor invoice recording (Part 2) Blog bot DAX Blogs 0 09.05.2017 12:11
emeadaxsupport: Corrupted data that may prevent you to post a purchase invoice Blog bot DAX Blogs 3 28.01.2013 11:32
emeadaxsupport: Why Purchase order invoice did not post any transaction on the balance account for Accounts payable Blog bot DAX Blogs 0 06.09.2012 04:43
dynamicsaxtraining: Purchase Blog bot DAX Blogs 0 11.03.2012 05:25
axinthefield: Optimizing AX Batch Performance - Batch Group Configuration Blog bot DAX Blogs 0 01.04.2011 13:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:03.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.