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

[lev]

У меня обсалютно тажа проблема, только на СКЛ2000... И заказы у нас по 2000 а то и по 3000 строк ... пробывали делить транзакции по строкам, не помогло..

[Волчара]

Цитата:

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

У меня обсалютно тажа проблема, только на СКЛ2000... И заказы у нас по 2000 а то и по 3000 строк ... пробывали делить транзакции по строкам, не помогло..

Господа специалисты, просьба ко всем: Давайте Больше Информации, иначе помочь очень трудно. Например, если один компьютер не видит другой компьютер, то дело может быть в плате, в шнуре, в программе, в настройках и т.е. Все это описать в виде ответа не реально - это статья или книга....

Делить транзакцию по строкам не помогло, совсем?
Надо делать так:
1. Попытаться зарезервировать строчку в отдельной транзакции
2. Если не помогло перейти к следующей строке
3. По завершении, попытаться повторно зарезервировать строчки, где были проблемы...
Если все сделано все правильно то эффект хоть какойто должен быть. Не забывайте его измерять по возможности более точно.

А если после одной не удачной строки отменять все предыдующие, или останавливать процесс, то конечно лучше не будет

Еще раз обращаю внимание, на железо: дело может быть еще и там.....

[AvrDen]

Возникла такая же проблема. В одной транзакции необходимо необходимо произвести резервирование заказа. Заказы бывают по 1000 и более строк. При параллельной обработке таких заказов (абсолютно разные номенклатуры и разные склады) возникают блокировки на InventSum в методе (InventUpd_Rezervation/updateRezerveMore). Тип блокировки Блокировка ключа индексации.
Может кто-нибудь за это время решил эту проблему..

[kashperuk]

Цитата:

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

Возникла такая же проблема. В одной транзакции необходимо необходимо произвести резервирование заказа. Заказы бывают по 1000 и более строк. При параллельной обработке таких заказов (абсолютно разные номенклатуры и разные склады) возникают блокировки на InventSum в методе (InventUpd_Rezervation/updateRezerveMore). Тип блокировки Блокировка ключа индексации.
Может кто-нибудь за это время решил эту проблему..

Конечно решили.
Разработчики Microsoft Dynamics AX 4.0

Также, следует почитать вот эту статью участника fed
http://www.ms-dynamics.ru/blog/2007/...s-ax-4-i-imts/

[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. Может какая-то идея хитрая была.

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

[Logger]

Цитата:

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

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

Дык...
Хочется же надеяться на лучшее.

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

Ну с обработкой заказов скорее всего на IMTS закладывались.