deadlock в кастомном батч джобе

[alicedr]

D365FO 10.0.20
Есть кастомный джоб на SysOperationsFramework, задача которого создать запись в таблице, выполнить запрос к внешнему ресурсу и проапдейтить запись с результатом запроса.

Выполняется все это дело по нескольким компаниям одновременно, а коткретно сразу в 6-8 компаниях и с 8 потоками в каждой компании.

В половине потоков наблюдаются дедлоки, жертвами являются практически все запросы на обновление (update) основной таблицы с транзакциями.

Все дедлоки наблюдаются в праймари индексе таблицы. Он уникальный и кластерный. Есть несколько других индексов, но они не уникальные и в дедлоках не светятся.

ВОПРОС: как решить вопрос с дедлоками? Как временное решение, праймари индекс был изменен на не-кластерный, пока тестируем.

Судя по наличию дедлока, в некоторых случаях сначала блокируется таблица, а потом индекс, а в других апдейтах сначала индекс а потом таблица.
Как определелить какой будет порядок блокирования по коду в X++?

Если же они блокируются в одинаковом порядке, то дедлоков по идее быть не должно, должны быть ожидания...

[Logger]

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

[alicedr]

Logger: Спасибо за идею, у меня тоже была такая, но, к сожалению, реализовать такое невозможно в данном случае.

[Stitch_MS]

Цитата:

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

Logger: Спасибо за идею, у меня тоже была такая, но, к сожалению, реализовать такое невозможно в данном случае.

А почему невозможно-то?

В крайнем случае сделайте две идентичных таблицы, А и Б. Запись-пустышку пишите в А и отправляйте запрос во внешнюю систему. После получения ответа вставляйте полную запись в Б и удаляйте старую запись из А одной транзакцией. Если нужно видеть все записи в одном гриде, сделайте вьюху типа Union.

Другой вариант - при апдейтах каждому из восьми процессов назначить свой диапазон обработки. Скажем, если первое поле в первичном ключе содержит ItemId, и все ItemId в системе начинаются с цифры, то первому процессу назначить «0*», второму «1*» или «1*, 2*» и т.д.

[alicedr]

Цитата:

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

А почему невозможно-то?

После получения ответа вставляйте полную запись в Б и удаляйте старую запись из А одной транзакцией.
.

При таком количестве потоков удаление будет провоцировать новые дедлоки. Но сама идея очень хорошая и у меня уже есть идеи где ее использовать )))

На самом деле проблема уже решена - мое предположение заменить кластерный индекс на некластерный сработало - за три дня не было ни одного дедлока при постоянном очень интенсивном тестинге.

[Vadik]

Цитата:

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

На самом деле проблема уже решена - мое предположение заменить кластерный индекс на некластерный сработало

Кластерный индекс был составной или состоял из одного поля? RecId, Guid, номерная серия в FO, еще что-то ? Если составной, были ли при обработке изменения в ключевых полях ?

[vmoskalenko]

Цитата:

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

Вы наверно создаете сперва запись пустышку, а затем обновляете ее, .... Попробуйте обойтись без обновления, только вставкой.

Поддерживаю. Кроме предложенного тут варианта использования второй таблицы. Можно еще сделать мапу из буферов в памяти. И хранить все не в таблице, а в памяти. Потом оттуда (из памяти) вставлять в таблицу.

Лучше избегать лишних операций с SQL.

[Vadik]

Цитата:

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

Выполняется все это дело по нескольким компаниям одновременно, а коткретно сразу в 6-8 компаниях и с 8 потоками в каждой компании
..
ВОПРОС: как решить вопрос с дедлоками?

Мысль #1: не зарываясь в детали (которых все равно в Вашем сообщении крайне мало чтобы пробовать чинить такое "по фотографии") - а не хотите сериализовать запуски этих джобов в рамках одной компании, поместив их тасками в один джоб вместо параллельных джобов?
Мысль #2: если такой сетап выбран осознанно и обработка неизбежных дедлоков реализована корректно - в чем проблема?

[alicedr]

Цитата:

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

Мысль #1: не зарываясь в детали (которых все равно в Вашем сообщении крайне мало чтобы пробовать чинить такое "по фотографии") - а не хотите сериализовать запуски этих джобов в рамках одной компании, поместив их тасками в один джоб вместо параллельных джобов?
Мысль #2: если такой сетап выбран осознанно и обработка неизбежных дедлоков реализована корректно - в чем проблема?

#1: это требование клиента, которого предупреждали о возможности дедлоков.
#2: обработка проведена корректно, но наличие дедлоков, особенно на продакшене, недопустимо так как сильно влияет на производительность всей БД. Не совсем понятно, почему возникают именно дедлоки, а не события ожидания, т.к. порядок вызова и, следовательно, блокирования обьектов БД одинаковый.

[trud]

А разве deadlock возможен на OCC enabled таблице? вы случайно не используйте update_recordset где-нибудь в коде?