Мертвые блокировки при резерве

[gl00mie]

Цитата:

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

Есть проблема - возникают мертвые блокировки при резервировании по заказу. В системе создана функция которая в одной транзакции резервирует все строки по заказу. Мертвые блокировки возникли на таблице InventSum. Первая догадка - мертвые блокировки возникают потому что при резервировании разных заказов номенклатуры в них перебираются в разном порядке. Чтобы этого избежать правильнее было бы везде при переборе строк заказа ставить сортировку по ItemId а также в классах ответственных за резервирование стараться чтобы аналитики перебирались в одном порядке.

Эх, а я надеялся это первым сказать Но уже опередили:

Цитата:

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

Конечно решили. Разработчики Microsoft Dynamics AX 4.0 Также, следует почитать вот эту статью участника fed http://www.ms-dynamics.ru/blog/2007/...s-ax-4-i-imts/

Именна шта!

Цитата:

От пользователей, работающих со старыми версиями Dynamics AX, достаточно часто приходится слышать жалобы на низкую производительность модуля логистики. Что нибудь типа “У нас стоит сервер БД на 4-х двухядерных Xeon (Opteron), 16 гигабайт оперативки и на небольшой 5 гигабайтной базе [...] можно увидеть длинную очередь блокировок процессов, причем все блокированные процессы ожидают освобождения записей в таблице inventSum

Непонятно, почему разработчики кода из sys-слоя только к 4-й версии додумались, что фигова туча кода завязана на обновление InventSum и выполнение различного рода логики по ходу этого обновления, из-за чего длительность блокировок нескольких записей может заметно затянуться. Цитата оттуда же:

Цитата:

Посмотрев на проблему свежим взглядом, разработчики (кстати – уже в Microsoft, a не в Navision), сделали простой вывод: Раз мы не можем отказаться от блокировки остатков, надо просто перенести операции блокировки остатков, их проверки и обновления в самый конец транзакции, чтобы блокировка (которая длится до конца транзакции) не длились слишком долго. Сделано это было следующим образом: При обновлении таблицы складских проводок (inventTrans), обновления в inventSum НЕ ПИШУТСЯ. Вместо этого добавляется информация об обновлении в таблицу inventSumDelta и inventSumDeltaDim. При этом делается это в основном соединении и транзакции – дополнительных соединений не открывается в принципе.

Отсюда - мораль: на 3-ке надо либо хирургически прикрутить механизм, применяемый в 4-ке (что чревато... и вообще непросто ), либо допиливать выявленные в данном конкретном случае "узкие места"...

Цитата:

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

А, ну вот я и пашел себе своей дорогой, раз Оракл ;-) Сори, тут я некомпетентен.

Тю! при чем тут Оракл? Это классическая схема возникновения клинчей (deadlock'ов, взаимоблокировок - как угодно), совершенно, к слову, не привязанная даже к полю деятельности СУБД. Код, выполняющийся в многозадачных ОСях, подвержен этому в не меньшей степени при использовании более чем одного объекта синхронизации. Правда, в тех же многозадачных ОСях есть обычно и штатные механизмы разруливания таких ситуаций (в виндах - SEH).

Цитата:

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

Вот я сижу и думаю, почему разработчики аксапты поставили везде сортировки по LineNum. Может какая-то идея хитрая была.

какая у этой басни мораль? а морали нет никакой, просто не сталкивались разработчкики резервирования с ситуацией, когда процесс резервирования по заказам осуществляется "двадцатью операторами с разных компьютеров".