Коллеги, что вы думаете о данном коде? 2MikeR

[belugin]

В первом письме темы можно нажать на >> в цитате

[S.Kuskov]

Вот ещё интересная реализация Модификация огромного количества (сотни тысяч) записей в Axapta 3.0 SP4

[MikeR]

Цитата:

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

Вот ещё интересная реализация Модификация огромного количества (сотни тысяч) записей в Axapta 3.0 SP4

Здорово, так все равно идет разбиение на отдельные транзакции, и НИКТО НЕ ГАРАНТИРУЕТ, что между i=5 и i=6 не произойдет бум!!
Целостьность, которую ставили выше всего так же страдает!!


ЗЫ может именно поэтому двенашка так сильно тормозит по сравнению с девяткой
Однако, политкорректненько вы плюсы раздаете

[S.Kuskov]

Примеры архитектурных решений:
Целостность данных при длительных запросах
Kurt Hatlevik: Review of inventory II

[MikeR]

Цитата:

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

Примеры архитектурных решений:
Целостность данных при длительных запросах
Kurt Hatlevik: Review of inventory II

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

[LeonDerCom]

Определение транзакции уже дает ответ на данный вопрос. И если каждое действие зависит от предыдущего - тогда делаем в одной транзакции, а если действия независимы - то какая разница? Произойдет бум в середине изменения состояния независимых записей - ну и ладно. Запустим заново и доделаем (в идеале, механизм проверки должен быть), иначе, транзакция по полной программе - зато данные в порядке.
То есть, сейчас вы спорите просто о том, кто и как для себя видит 1 единицу действия сферического коня в вакууме... Ответ на вопрос зависит только от предпочтений и опыта программиста в в каждом конкретном случае.

[Kabardian]

ИМХО:

1. Согласен с Belugin про целостность данных, суть транзакции никто не отменял!
2. Best practice, которые привел MikeR не говорят о том, что надо вообще любые обновления данных делать вложенными в while select forupdate транзакциями. Они говорят как можно уменьшить количество обращений к базе данных и извлечь пользу от оптимистической модели. Это надо применять предельно осторожно и осознанно.
3. Чтобы было совсем по best practice в пример MikeR необходимо в запрос добавить optimisticlock, чтобы оптимистичная модель применялась независимо от настроек таблицы в которой выполняется обновление данных:

   while select optimisticlock ...

4. Касательно примера, который привел MikeR, я его не буду комментировать, но поясню на примерах из книги Inside Dynamics AX 2012 (см. стр. 444-446), где рассматривается пример обновления кредитного лимита для всех клиентов:
   
   ПРИМЕР №1:
   

   static void UpdateCreditMax(Args _args) 
   { 
       CustTable custTable; 
       
       ttsBegin; 
       while select forupdate custTable where custTable.CreditMax == 0 
       { 
           if (custTable.balanceMST() < 10000) 
           { 
               custTable.CreditMax = 50000; 
               custTable.update(); 
           } 
       } 
       ttsCommit; 
   }

   Особенности:
   • В случае сбоя либо все данные обновятся, либо нет.
   • Записи блокируются на все время обновления, однако, если включена оптимистичная модель, то блокировка снимается с записей по мере их обновления
   • На уровне базы данных SQL будут выполнены операции: 1 select + 100 update
   
   ПРИМЕР №2:
   

   static void UpdateCreditMax(Args _args) 
   { 
       CustTable custTable; 
       CustTable updateableCustTable; 
       
       while select custTable where custTable.CreditMax == 0 
       { 
           if (custTable.balanceMST() < 10000) 
           { 
               ttsBegin; 
               select forupdate updateableCustTable 
               where updateableCustTable.AccountNum == custTable.AccountNum; 
               updateableCustTable.CreditMax = 50000; 
               updateableCustTable.update(); 
               ttsCommit; 
           } 
       } 
   }

   Особенности:
   • В случае сбоя часть данных будет обновлена, а часть - нет
   • Блокируется только 1 запись, которая обновляется в данный момент
   • На уровне базы данных SQL будут выполнены операции: 1 select + 100 select + 100 update
   
   ПРИМЕР №3:
   

   static void UpdateCreditMax3(Args _args) 
   { 
       CustTable custTable; 
       
       while select optimisticlock custTable where custTable.CreditMax == 0 
       { 
           if (custTable.balanceMST() < 10000) 
           { 
               ttsBegin; 
               custTable.CreditMax = 50000; 
               custTable.update(); 
               ttsCommit; 
           } 
       } 
   }

   Особенности:
   • В случае сбоя часть данных будет обновлена, а часть - нет
   • Блокируется только 1 запись, которая обновляется в данный момент
   • На уровне базы данных SQL будут выполнены операции: 1 select + 100 update
   
   ИТОГО:
   • Вариант № 2 не следует использовать совсем
   • Среди вариантов №1 и №2 выбирать необходимо в зависимости от конкретно поставленной задачи таким образом, чтобы в случае сбоя системы целостность данных не пострадала и для пользователя все было прозрачно и понятно - либо пан, либо пропал.

И еще, хорошая статья со сравнением пессимистичной и оптимистично модели обновления данных:
About locking and blocking in Dynamics AX and how to prevent it

[AndyD]

Цитата:

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

[*]Записи блокируются на все время обновления, однако, если включена оптимистичная модель, то блокировка снимается с записей по мере их обновления

Что-то вы путаете

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

Это если будет использоваться оптимистическая модель блокировок

При пессимистической в конечном счете, скорее всего, будет заблокирована вообще вся таблица (конечно, сильно зависит от распределения данных по компаниям)

[Kabardian]

Цитата:

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

Что-то вы путаете

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

Может выразился некорректно, поясню. Например, есть 3 записи, которые обновляются в запросе:

• Запись1
• Запись2
• Запись3

В таком случае, все записи сначала блокируются, затем система обновляет их все по порядку и в процессе обновления снимает блокировки следующим образом (оптимистичная модель):

• Обновлена Запись 1 - блокировка с снята с Записи 1
• Обновлена Запись 2 - блокировка с снята с Записи 2
• Обновлена Запись 3 - блокировка с снята с Записи 3

Поэтому, убежден, что я ничего не путаю.

[AndyD]

Не, не понятно

Блокировка, наложенная при обновлении, держится до момента окончания транзакции
Независимо от модели блокировок Аксапты - сиквел об этом вообще ничего не знает

[belugin]

Если отпустить блокировку после обновления записи, но до коммита транзакции, то у конкурирующей транзакции может случиться "грязное чтение", например. Так что AndyD говорит все верно.

[Kabardian]

Belugin, AndyD, может я и в самом чего-то не понимаю, процитирую статью About locking and blocking in Dynamics AX and how to prevent it (ссылку на нее давал выше):

[belugin]

График противоречит тексту над ним (выбираем без блокировки, при это после обработки 1/6 записей все они заблокированы)

[Kabardian]

Цитата:

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

График противоречит тексту над ним (выбираем без блокировки, при это после обработки 1/6 записей все они заблокированы)

График не противоречит тексту. График одновременно объясняет работу оптимистичной и пессимистичной модели, поэтому надо вчитываться внимательней, чтобы понять.

Цитата:

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

Ко всему прочему, там нет ни слова о снятии блокировок после апдейта

А это тогда о чем? (текст сразу под графиком)

Цитата:

When using OCC the positive effect is obvious: There are much more rows available for updating (the olive bars). When we would have PCC the olive bars would not be available for updating, or in the words another process / tranaction would be blocked until all rows are processed. So when using OCC the chances for blocking is much smaller.

[belugin]

Цитата:

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

А это тогда о чем? (текст сразу под графиком)

Там не написано про блокировки после апдейта ничего. OCC работает так:

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

Если бы этого не было, то возможен был бы следующий сценарий.

Например некая транзакйия хочет выбрать две записи и их изменить. Если она не заблокирует первую запись до конца транзакции, то при этом другая транзакия сможет увидеть ее содержимое до конца первой транзакции и пойдет дальше с учетом этих грязных данных (dirty read). Первая транзакция может быть откатана, напрммер, потому что вторую запись успела изменить третья транзакция (после чтения первой и до сохранения). И тогда у нас будут в базе данные частично как будто первая транзакция завершилась успешно (в первой записи) в частично как будно нет (во второй)

[AndyD]

Угу, подписи перепутаны. Должно быть наоборот

Ко всему прочему, там нет ни слова о снятии блокировок после апдейта

[AndyD]

Замечу так же, что при блокирующем чтении блокировки на выбираемые записи накладываются не на весь набор сразу, а по мере чтения записей.
Учитывая, что Аксапта использует серверные курсоры и данные вычитываются из таблицы порциями, картина блокировок будет не сильно отличатся от приведенной для оптимистического сценария. Только кол-во блокировок будет нарастать не пропорционально обновлению, а пропорционально чтению

Естественно, это справедливо для случая обновления всех прочитанных записей и без эскалации блокировок

[AndyD]

Переверните все-таки подпись к оси ординат и все встанет на свои места

А в тексте предполагается единомоментное наложение блокировки при блокирующем чтении (что не соответствует действительности) - т.е. график будет в виде "кирпича", а не красивых ступенек, которые, якобы, уменьшают вероятность блокировок

[fed]

Цитата:

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

Переверните все-таки подпись к оси ординат и все встанет на свои места

А в тексте предполагается единомоментное наложение блокировки при блокирующем чтении (что не соответствует действительности) - т.е. график будет в виде "кирпича", а не красивых ступенек, которые, якобы, уменьшают вероятность блокировок

А ты можешь привести какую-то ссылочку в подтверждение ?

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

Кроме того - как-то мне казалось что как раз при работе с серверными курсорами, система фетчит выборку, потом засовывает во временную таблицу в tempdb и потом по ней навигирует (естественно - заблокировав все скопированные записи в исходной таблице).

[Kabardian]

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

Belugin, AndyD, спасибо за подробные ответы.