[kgksoft]

Цитата:

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

Поздравляю с решением проблемы, но описание не очень понятно.
1. О каком кол-ве операций(в час к примеру) идет речь
2. Почему не использовали предварительное выделение номеров
3. Как я понял вы сделали обновление на SQL вне зависимости от кол-ва строк. OCC это же сво-во в АХ, как оно влияет вообще на ?
4. Какой объем InventSum если выполнить следующий скрипт

О, хоть кому-то интересен мой "прорыв года".

1. около 5 вызовов в секунду, но это тяжелых корзин (1-5 позиций), логика резервирования довольно тяжелая 0,5-10 секунд на вызов. Физически описываемая выше операция естественно в самом конце на комите.
2. Предварительное выделение было включено, но оно работает в пределах одного АОСа, а у меня их много и расходуются номера не оптимально при больших предварительных значениях. К тому же уже написан функционал по быстрой настройке любой номерной серии на использование 64-бит или номерных серий MSSQL. Это намного быстрее, чем стандарт с его блокировкой строки.
3. Да, ОСС это свойство таблицы. И кода, который выбирает InventSum forUpdate не так много. Главное даже не это свойство, а то что не нужно вообще делать выборку для блокировки. Во время тестирования наблюдались блокировки на вызовах select updlock, которые пытались залочить строки для обновления. После переделки блокировки ушли.
   Происходило две операции (Блокировка и Обновление), а теперь блокировка происходит на уровне SQL одной операцией update qty += delta.
   По идее, та же проблема должна быть и с кодом по обновлению WHSInventReserve, но проблемы с этой таблицей не наблюдал и отложил переделку до следующего раза.
4. 
   number---Closed---ClosedQty
   884676---0---0
   17619789---0---1
   2699511---1---1