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

[MikeR]

Цитата:

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

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

Правильно ли я тебя понимаю, что когда, допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию, вешать блокировку while select forupdate по обновляемым таблицам? Иначе тоже может произойти пук и мы потеряем целостность, то есть запишем в таблицу налогов одни цифири, а допустим документы не обновим.

[S.Kuskov]

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

[MikeR]

Цитата:

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

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

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


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

[macklakov]

Цитата:

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

Правильно ли я тебя понимаю, что когда, допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию

Насколько я понимаю, именно в этом смысл транзакции и есть.

[S.Kuskov]

Цитата:

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

допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию, вешать блокировку while select forupdate по обновляемым таблицам?

Если объемы необходимых изменений столь велики, то методологически правильно сначала вне транзакции выполнить все долгие вычисления и получить "грязные" данные, а потом в одной транзакции минимально затратным способом их применить "на чисто", естественно убедившись что с момента вычисления данные не устарели. Конечно поддержка такого рода механизмов изначально должна быть заложена в архитектуру данных. Например, хорошо когда архитектура данных позволяет вместо полного пересчета устаревших данных, учесть в новом расчете только новые изменения, произошедшие с момента предыдущего расчета.

И даже здесь возникает дилемма, что лучше заблокировать два десятка таблиц на 5 минут и гарантированно выполнить разноску? Или пересчитывать постоянно меняющиеся данные до посинения? Это уже организационный вопрос и решать его нужно организационными методами. Например, если оперативность разноски не критична, то выносить такую разноску в пакетное задание на ночь.

[S.Kuskov]

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

[MikeR]

Цитата:

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

И даже здесь возникает дилемма, что лучше заблокировать два десятка таблиц на 5 минут и гарантированно выполнить разноску? Или пересчитывать постоянно меняющиеся данные до посинения? Это уже организационный вопрос и решать его нужно организационными методами. Например, если оперативность разноски не критична, то выносить такую разноску в пакетное задание на ночь.

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

[MikeR]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

Давайте исходить из предложенного примера. MikeR,
- что произойдет, если нерадивый админ кильнет aos32 на середине процесса обновления таблицы? (случится креш аоса, пропадение связи и прочее - кстати, код на сервере выполняется?)
- что произойдет если два пользователя запустят этот процесс одновременно
- используется ли на изменяемой таблице оптимистичная или пессимистичная блокировка и как измениться поведение "совсем уж мелких деталей" при этом.

P.S. По моему опыту есть некий оптимум по скорости обновления записей и он может находиться где-то между "все записи сразу" и "каждая запись отдельно". Т.е. может быть более выгодно обновлять пакетами по n записей.

[MikeR]

2belugin я почему открыл обсуждение, что ОПТИМИСТИЧЕСКАЯ МОДЕЛЬ НЕ СОГЛАСУЕТСЯ С ЦЕЛОСНОСТЬЮ, даже inventTrans оптимистический. И ведомые языческами богами других систем народ продавливает производительность. Или давайте возвращаться к писиместической модели, и тогда код написанный нерадивым коллегой будет корректен. Почему нерадивым -у него посто куча разных ляпов, ключевое поле guid, допустим, об осталном уже писал. Он просто пытался подделать то, что знал из другой системы в аксапту. А здесь другая религия. Никто к пессимизму не вернется, так как по производительности будет полный провал. Хотя стоит отметить есть и другие реализации, но их мало.

[belugin]

Цитата:

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

Правильно ли я тебя понимаю, что когда, допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию,

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

См. также давнишнюю статью Fed'а про то, как избегают блокировок в inventory

[belugin]

Цитата:

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

2belugin я почему открыл обсуждение, что ОПТИМИСТИЧЕСКАЯ МОДЕЛЬ НЕ СОГЛАСУЕТСЯ С ЦЕЛОСНОСТЬЮ

Расшифруй?

Цитата:

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

Это завсит от вероятности коллизии на конкретной таблице. (Знаешь, почему одна модель называется оптимистической, другая пессимистической)?

[someOne]

Цитата:

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

Для карсоты решения еще раз приведу утверждения

5 Корректный код

while select ItemId 
    from salesLine 
{ 
    select firstOnly forUpdate ItemType, ItemBuyerGroupId  
       from inventTable 
           where inventTable.ItemId == salesLine.ItemId; 
 
    If (inventTable && (inventTable.ItemType == InventItemType::Item)) 
    { 
        ttsBegin; 
        inventTable.ItemBuyerGroupId = ; 
        inventTable.update(); 
        ttsCommit; 
    } 
}

Вот до кучи еще вариант: (без всяких ttsbegin вообще)

while select ItemId 
    from salesLine
join inventTable
where inventTable.itemid == salesLine.itemId &&
inventTable.ItemType == InventItemType::Item  
{ 
        update_recordset inventTableUpd
        setting inventTableUpd.ItemBuyerGroupId = 
        where inventTableUpd.ItemId == salesLine.ItemId;
}

Кстати к вопросу о производительности БД. Множество ttsbegin --> ttscommit не всегда лучший вариант для производительности БД.

Объединение множественных обновлений в одну транзакцию - это конечно блокировки - но более производительный вариант для БД ИХМО.

[MikeR]

someOne хороший варинат, если покурсовый не перекрыт.

[S.Kuskov]

Цитата:

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

Вот до кучи еще вариант

А в чем профит от использовании групповой операции применительно к одной записи?

[fed]

Цитата:

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

А в чем профит от использовании групповой операции применительно к одной записи?

Один запрос к SQL Server вместо двух...

[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

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