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

[AndyD]

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

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

[belugin]

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

[Kabardian]

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

[belugin]

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

[AndyD]

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

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

[AndyD]

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

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

[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]

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

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

[Kabardian]

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

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

[AndyD]

В качестве факультатива - попробуйте найти в сиквеле команду на снятие блокировки

Кроме завершения транзакции

[fed]

Цитата:

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

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

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

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

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

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

[AndyD]

Цитата:

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

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

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

Вешает, но таблицу накладывается блокировка намерения на эксклюзивный доступ
Простым блокировкам обновления это не препятствует

Блокировка намерения обновления страниц вешается же при фетче - но она, опять же, не мешает блокировке строк

Цитата:

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

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

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


Что бы убедиться, можно сделать простой тест - запустить нижеприведенный код в разных сессиях одновременно, без прерывания паузы (во второй сессии сортировка в выборке должна быть в обратном порядке)

    InventTable inventTable;
    ;
    
    ttsbegin;
    
    select pessimisticLock inventTable
    order by itemId;
    //order by itemId desc; - для запуска во второй сессии
    
    pause;
    ttsabort;

Если записей в таблице достаточно, то в результате оба запроса вернут результат

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

[AndyD]

Вот, кстати, и ссылка Блокировка курсора
Речь там, правда, про курсоры TransactSQL, но к серверным курсорам это так же применимо (см. про динамические курсоры)

[MikeR]

Цитата:

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

Расшифруй?

Там, кстати по SQL север где ссылку положили есть такое определение:
" Если пользователь пытается изменить строку, то ее текущие значения сравниваются со значениями, полученными во время последней выборки этой строки. Если какое-либо значение изменилось, то сервер определяет, что другой пользователь или процесс уже обновил эту строку, и возвращает ошибку. Если значение остается прежним, то сервер выполняет изменение."
http://technet.microsoft.com/ru-ru/l...ql.105%29.aspx
В писсимистичесой модели все становятся в очередь и терпиливо ждут первый процесс, ну или какой там тормозит. Вот это я и имел в виду, что писсимистическая в плане целостности лучше работает, чем оптимистическая. То есть оптимистическая абортирует затормозившие процессы, без стыда и совести.

[Vadik]

Цитата:

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

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

Специальный тип исключения UpdateConflict и макрос OCCRetryCount в системе для красоты живут, надо полагать ?

[belugin]

Цитата:

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

. То есть оптимистическая абортирует затормозившие процессы, без стыда и совести.

В этом случае предлагается повторить транзакцию.

У тебя свое определение целостности.

http://en.m.wikipedia.org/wiki/Consi...tabase_systems)

In database systems, a consistent transaction is one that starts with a database in a consistent state and ends with the database in a consistent state. Consistent state means that there is no violation of any integrity constraints. Consistency may temporarily be violated during execution of the transaction, but must be corrected before changes are permanently committed to the database. If the transaction would leave the database in an illegal state, it is aborted and an error is reported.[1]

[MikeR]

Итого резюмируя, как же все таки сделать озвученный код оптимальнее и с минимальными затратами, а так же с учетом фич, которые появились в AX 2012.

While select InvGuid, ParentInvGUID,recId from current WHERE current.InvGuid == InvGUID
        Join RecId from parent WHERE parent.InvGUID  == current.ParentInvGUID
{

            SELECT FIRSTONLY RecId, AMOUNTCUR from 
            parentDistr
            WHERE parentDistr.InvGUID == InvGUID &&
                parentDistr.TransRecId == inventoryGuidInvoice.TransRecId
                //...........
                && parentDistr.JuridicalPersonId == inventoryGuidInvoice.JuridicalPersonId;
//...........
            if(parentDistr.RecId)
            {
                update_recordset parentDistrUpd
                setting 
 parentDistrUpd.AMOUNTCUR += inventoryGuidInvoice.AmountCur;//слияние к предку
            }
            else
            {
                RecordInsertList.add(InventoryGuidInvoice);
            }
    }

Далее просто

RecordInsertList.insertDatabase();

По поводу фич: в двенашке появились временные таблицы tempDB, чуть по-больше создав дополнительно таблицы для наполнения промежуточных расчетов, можно практически уйти от блокировок и все связанного, делая в конце расчета одной операцией либо обновление, либо вставку данных в базовые таблицы.

Я вообще считаю, что циклы должны быть конечными при любом раскладе, любое использование обратного приводит к некоторой расхлябанности в коде и как следствие падению производительности. Пусть лучше разработчик доказывает, что необходимо использовать именно while(true), чем закрывать на это глаза с самого начала. В принципе правильно спланированное приложение позволит выполнять запросы без while(true) и Left Join, на самом деле это уже вопрос более к архитектору приложения, нежели к разработчику. Про использование fieldList, соединений таблиц не говорю, так как этого полно можно прочитать в тренингах.

PS Да и всеж таки код с таблицами tempDB будет с точки зрения целостности, за которую идет война не одну страницу, будет более правильным, в одной транзакции одной операцией. Единственный минус - создание дополнительных объектов в репозитарии.
И не надо ждать ночи на пакетные задания

[belugin]

Eсли while убран, то этот код в отличие от исходного обновит только один уровень (например, если уипарента был еще парень). Цикл там все-таки был не зря, хотя while (true) это конечно code smell не потому, со он "бесконечный" а потому, что условия выхода написаны в необычном месте. С транзакциями стало непонятно - если одна общая(где-то раньше ttsbegin одно, если несколько, то другое.

Интересно также, что произойдет если две транзакции попробуют создать запись в distr одновременно

[MikeR]

Цитата:

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

С транзакциями стало непонятно - если одна общая(где-то раньше ttsbegin одно, если несколько, то другое.

Интересно также, что произойдет если две транзакции попробуют создать запись в distr одновременно

Как уже позже описал - из tempDB таблиц (одна на вставку, одна обновление) в одной транзакции

ttsbegin;

//update
//insert

ttscommit;

ЗЫ Хотя знаешь, update то придется опять таки в цикле делать
А ты что нибудь можешь предложить конструктивного?