Статья о новом механизме блокировок складских остатков в Ax 4.0

[lev]

Наткнулся здесь на статью Dynamics AX 4 и IMTS, в которой рассказывается о новом подходе к обновлению состояния складских запасов (InventSum).

Выжимка из статьи:

Цитата:

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

Одной операцией блокируются ВСЕ остатки в inventSum, подлежащие изменению в результате обновления складских проводок в данной транзакции. При этом блокировка выполняется как атомарное действие, то есть не может возникнуть ситуация при которой мы заблокировали 12 остатков из 20; Затем на 13ом остановились и стали ждать пока чужая сессия освободит этот 13ый остаток, продолжая при этом удерживать первые 12 остатков. Соответственно – не возникает ситуации разрастания дерева блокировок.
Система пробегает по таблице InventSumDelta (и связанной с ней inventSumDeltaDim) и для каждого обновления проверяет – не случилась ли у нас ситуация отрицательного остатка. Если такая ситуация случилась – выдается сообщение об ошибке и транзакция откатывается.
После проверки очередной записи в inventSumDelta, система обновляет соответствующую запись в inventSum, а запись в inventSumDelta и inventSumDeltaDim просто удаляет.
Как результат:

Проблемы, вызванные использованием второго соединения и обходом штатного механизма транзакций СУБД – отсутствуют. В версии 4.0 все обновления inventSum делаются в одном соединении и транзакции.
Проблемы вызванные разрастанием дерева блокировок (характерные для работы старых версий системы с отключенным IMTS) также отсутствуют, поскольку используется атомарная блокировка СРАЗУ ВСЕХ необходимых для выполнения транзакции ресурсов.
Проблемы собственно блокировки остатков сведены к минимуму, поскольку блокировка выполняется перед самым завершением транзакции, а операции выполняемые системой после блокировки – легкие, короткие и не требуют для выполнения много времени и ресурсов.
Кстати сказать – для ускорения обновления таблицы inventSum, разработчики использовали direct SQL (То есть – использование запросов к СУБД в native диалекте, в обход стандартного механизма Dynamics AX). В случае MS SQL на сервер отправляется могучий запрос на целый экран с несколькими case и другими, отсутствующими в стандартном SQL-диалекте DAX расширениями. В случае Oracle, обновление inventSum вообще делается хранимой процедурой AxUpdateInventOnHand, создаваемой при первой синхронизации. Хотя такой подход, строго говоря, является нарушением требований best practice, но в данном случае его применение вполне оправдано.

Хочу также заметить, что проверка остатка при завершении транзакции не отменила проверку остатка при изначальном выполнении операции списания. Так что если мы пытаемся зарезервировать или продать товар, которого в принципе нет на складе, нам не придется ждать завершения транзакции чтобы получить информацию о невозможности такого действия.

Единственный возможный минус нового режима блокировки запасов в наличии - это чуть большее количество откатов транзакций, возникающих в тех случаях, когда при первоначальном выполнении списания товар еще был, а при окончательной проверке и коррекции остатка - выяснилось что по дороге этот товар кто-то уже списал (зарезервировал и тд). Большой дополнительной нагрузки на сервер БД эти откаты транзакций создавать не будут, поскольку в реальной жизни такие ситуации случаются не очень часто. Если между сотрудниками существует такая большая конкуренция за товар, то на практике он распределяется организационным образом, а не по принципу - “кто первый встал - того и сапоги”

Фактически - реализованный в DAX 4.0 механизм блокировки остатков является вариацией оптимистического режима блокирования СУБД. В классическом варианте этот режим работает следующим образом:

При чтении данных внутри транзакции, таковые не блокируются.
При обновлении данных внутри транзакции, система проверяет - не были ли они обновлены другой сессией после чтения в текущей транзакции. Если такая ситуация возникла - генерируется сообщение об ошибке и транзакция откатывается.
В случае обновления остатков, подобный механизм в чистом виде будет генерировать слишком много ошибок. Поэтому в DAX он реализован таким образом, чтобы в ошибка выдавалась только в том случае, если из за обновлений других сессий складского остатка не хватило для выполнения нашей операции. То есть - контролируется не факт изменения данных другой сессией, а факт захвата критически большого для нашей операции количества другой сессией.

Надо отметить, что оптимистический механизм блокировки информации о запасах не имеет ничего общего с оптимистическим механизмом оценки запасов (из IMTS 3ей версии). Это разные типы оптимизма В первом случае - оптимистически оценивается вероятность завершения НАШЕЙ транзакции, то есть - если хватило запасов в момент создания складской проводки, то наверное, хватит их и в момент завершения транзации и контроля остатков. Во втором - оптимистически оценивается вероятность завершения ЧУЖИХ транзакций , то есть - если чужая незавершенная транзакция оприходовала товар, то скорее всего эта транзация не будет откачена.

Таблица InventSumLogTTS в 4ой версии DAX осталась, но обновляется она в рамках основной транзакции и используется только для сводного планирования. (Чтобы сводное могло понять, какие складские проводки менялись за последнее время и обновить связанные с этими проводками чистые потребности).

Надо сказать, что разработчикам все-таки пришлось в двух местах системы наступить на горло собственной песне и все-таки дописать кусочек кода, который для расчета остатка использует не только данные их inventSum, но и данные об обновлениях (inventSumDelta), выполненных в рамках ТЕКУЩЕЙ транзакции. Эти места – подстановка складской аналитики в зерезвировании и подбор номера палетты в расширенном складе. Представим себе ситуацию, при которой у нас в заказе есть две строки с одинаковой номенклатурой и мы в рамках одной транзакции резервируем эти строки, рассчитывая что система подберет нам правильные номера партий, присутствующих на складе. В старой версии, система просто подбирала номера партий, пробегаясь по запасам в наличии. Однако – поскольку в новой версии, обновление inventSum отложено до самого конца транзакции, то попытка резервировать по старому алгоритму, приведет к тому, что по второй строке будут зарезервированы те же самые партии что и по первой. Поэтому, разработчикам пришлось при резервировании, использовать данные не только из запасов в наличии, но и из таблицы inventSumDelta. С точки зрения нагрузки на систему и вероятности блокировки это не приводит к негативным последствиям, однако в целом несколько портит концептуальную целостность красивой идеи.

В заключение хочу заметить, что перенести этот механизм на версию 3.0 не представляется возможным, в связи с тем что в старых версиях Dynamics AX отсутствовал метод application.ttsNotifyPreCommit, вызывающийся ПЕРЕД завершением транзакции. Описанный в данной заметке механизм, основан на классе InventUpdateOnHand, вызывающемся из данного метода. В старой версии - были только методы application.ttsNotifyCommit, application.ttsNotifyAbort вызывающиеся ПОСЛЕ завершения транзакции."

прочитав статью у меня появилось несколько вопросов

1. Действительно ли, начиная с четвертой версии аксапты, проблема с блокировками стала менее актуальной? На сколько хорошо работает этот механизм в нашей повседневной аксаптовской жизни?

2. Перекачевал ли такой подход в Ax2009 или там пошли ещё дальше, и вообще побороли блокировки?
Если кто знает где почитать про решение данной проблемы в Ax2009, дайте ссылку плиз (ну или просто кто знает, расскажите)

Заранее спасибо за ответы

[fed]

Дело давнее, но поскольку статья все равно моя - отвечу:
1. Действительно проблема с блокировками inventSum почти ушла. Блокировки короткие. Правда на практике, если поститься очень большой складской журнал (типа 1000 строк в одной транзакции) и у тебя большой размер таблицы inventDim (типа серийники и номера партий используешь активно), блокировка может висеть секунд 15-20. Это гораздо лучше чем было в версии 3.0, но все равно некоторые блокировки вызывает. Но вряд ли эта проблема в принципе решаема.
2. В 2009ую данный подход перекочевал. Ничего кардинально не изменилось...

[S.Kuskov]

Цитата:

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

1. Действительно ли, начиная с четвертой версии аксапты, проблема с блокировками стала менее актуальной? На сколько хорошо работает этот механизм в нашей повседневной аксаптовской жизни?

К сожалению мне не с чем сравнить. На 3.0 довелось поработать совсем не много. А у вас есть какие-то конкретные поводы сомневаться в действенности этих нововведений?

Цитата:

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

Перекачевал ли такой подход в Ax2009

Да. В AX2009 тоже есть таблицы InventSumDelta и InventSumDeltaDim. Более того аналогичный подход применили для балансов главной книги fed: Ledger Balance Data in DAX

Цитата:

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

или там пошли ещё дальше, и вообще побороли блокировки?

Если хотите совсем без блокировок, то тогда вам нужно что-то вроде этого Kurt Hatlevik: Review of inventory II

[lev]

Цитата:

Сообщение от S.Kuskov

К сожалению мне не с чем сравнить. На 3.0 довелось поработать совсем не много. А у вас есть какие-то конкретные поводы сомневаться в действенности этих нововведений?

ну я всегда сомневаюсь и проверяю не всегда то, что реализовано в системе, работает на 100% так как задумывалось поэтому и уточнил

за ссылки спасибо, почитаю