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

[Stitch_MS]

Цитата:

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

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

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

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

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

[alicedr]

Цитата:

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

[alicedr]

Цитата:

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

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

Одно поле. transId. Никакх изменений, кроме clustered -> non-clustered