deadlock в кастомном батч джобе
D365FO 10.0.20
Есть кастомный джоб на SysOperationsFramework, задача которого создать запись в таблице, выполнить запрос к внешнему ресурсу и проапдейтить запись с результатом запроса.
Выполняется все это дело по нескольким компаниям одновременно, а коткретно сразу в 6-8 компаниях и с 8 потоками в каждой компании.
В половине потоков наблюдаются дедлоки, жертвами являются практически все запросы на обновление (update) основной таблицы с транзакциями.
Все дедлоки наблюдаются в праймари индексе таблицы. Он уникальный и кластерный. Есть несколько других индексов, но они не уникальные и в дедлоках не светятся.
ВОПРОС: как решить вопрос с дедлоками? Как временное решение, праймари индекс был изменен на не-кластерный, пока тестируем.
Судя по наличию дедлока, в некоторых случаях сначала блокируется таблица, а потом индекс, а в других апдейтах сначала индекс а потом таблица.
Как определелить какой будет порядок блокирования по коду в X++?
Если же они блокируются в одинаковом порядке, то дедлоков по идее быть не должно, должны быть ожидания...
|