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

[AndyD]

Цитата:

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

Для AndyD DO NOT: Hold database locks for longer than is necessary.
DO: Limit the transaction scope by grabbing locks at the latest possible time and
releasing locks as early as possible.

Не могу отвечать в закрытой теме

Какое отношение это имеет к исходному вопросу?
По вашему, транзакция нужна только потому, что Аксапта иначе не дает апдейт сделать?

[MikeR]

Цитата:

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

Не могу отвечать в закрытой теме

Какое отношение это имеет к исходному вопросу?
По вашему, транзакция нужна только потому, что Аксапта иначе не дает апдейт сделать?

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

[MikeR]

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

1 С чего все началось:

ttsbegin;
    WHILE(TRUE)
    {
        SELECT FIRSTONLY current WHERE current.InvGuid == InvGUID;
        InvGUID = current.ParentInvGUID;

        SELECT FIRSTONLY parent WHERE current.ParentInvGUID == parent.InvGUID;

        if(parent)
        {
            //parentDistr.disableCache();
            SELECT FIRSTONLY
            FORUPDATE parentDistr
            WHERE parentDistr.InvGUID == InvGUID &&
                parentDistr.TransRecId == inventoryGuidInvoice.TransRecId
                //...........
                && parentDistr.JuridicalPersonId == inventoryGuidInvoice.JuridicalPersonId;

            if(parentDistr)
            {
                parentDistr.AMOUNTCUR += inventoryGuidInvoice.AmountCur;//слияние к предку
                //.......
                parentDistr.Update();
            }
            else
            {
                parentDistr.data(InventoryGuidInvoice);
                parentDistr.InvGUID = parent.InvGUID;
                parentDistr.insert();
            }
        }
        else
        {
            break;
        }

        current.clear();
    }
    ttscommit;

2 Моя формулировка

while select
{
	ttsbegin;
	select forupdate 
	ttscommit;
}

3 Что гласит документация :

DO NOT: Hold database locks for longer than is necessary.
DO: Limit the transaction scope by grabbing locks at the latest possible time and
releasing locks as early as possible.

4 Не корректный код, читай в п1

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

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; 
    } 
}

[MikeR]

Собственно написал, что бы было понятно ищущим знаний коллегам.

[ackid]

Я считаю что при необходимости вполне можно транзакцию вне цикла открывать... но вот потенциально бесконечный цикл....блин...как вижу этот true так в дрожь))))

[Ruff]

MikeR, в ваших примерах из п. 4 и 5 идет обработка плоских данных, для которых отмена части транзакций не критична, ибо они могут быть выполнены позже простым повторным запуском того же кода. А в исходном алгоритме (п. 1) идет обход узлов дерева, причем выполняется операция +=. Если такой обход раздробить на мелкие транзакции, то при их частичном откате восстановить целостность данных будет невозможно физически (если явно не хранить историю обновления).
Ну а пример из п. 2 (while select...) неприменим для обхода дерева при заданной в п.1 структуре данных.
Наверное это вам и пытаются сказать...
PS: С тем, что п.5 более корректен в общем случае, чем п.4 - согласен.

[MikeR]

Цитата:

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

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

Что сказали, то сказали, бумага все стерпит.
С плоскими разобрались, так понимаю. НО ДАЖЕ в иерархической реализации это дает результат. Представляете если это достаточно большой пул проводок. Все напрочь блокируется, а какова вероятность, что произойдет исключительная ситуация? На практике это менее 5 процентов. Что стоит каждый раз терпеть блокировки или тупо следовать надуманной целостности, которая даже еще и не думала нарушаться...
Не говоря о том, что по мелочам
1)

        SELECT FIRSTONLY current WHERE current.InvGuid == InvGUID;
        InvGUID = current.ParentInvGUID;

        SELECT FIRSTONLY parent WHERE current.ParentInvGUID == parent.InvGUID;

спокойно сливается в одни запрос
2)

parentDistr.AMOUNTCUR += inventoryGuidInvoice.AmountCur;//слияние к предку

легко используется агрегатная функция.

[ax_mct]

Цитата:

Сообщение от 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; 
    } 
}

И все же насколько обоснованно выбирать буфер для обновления (forUpdate) ВНЕ транзакции (ttsbegin…ttscommit)? Типа код оптимизирован для уменьшения блокировок путем перемещения tts* ?
Что мешает при той же оптимизации выбирать внутри транзакции? Не знаю, у меня глаза режет от такого.
Почему бы не так:

while select ItemId 
    from salesLine 
{ 
    select firstOnly ItemType, ItemBuyerGroupId  
       from inventTable 
           where inventTable.ItemId == salesLine.ItemId; 
 
    If (inventTable && (inventTable.ItemType == InventItemType::Item)) 
    { 
        ttsBegin; 
        [B]inventTable.forupdate(true);[/B]
        inventTable.ItemBuyerGroupId = ; 
        inventTable.update(); 
        ttsCommit; 
    } 
}

Я возможно не прав, но глаза

[MikeR]

Цитата:

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

Что мешает при той же оптимизации выбирать внутри транзакции?

Согласен, но это уже совсем мелкие детали.

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

[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 вместо двух...

[belugin]

тут вся загвоздка в слове necessary - устраивает ли тебя если в случае проблем с сетью половина строк обновится, а половина, нет

[Vadik]

Цитата:

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

тут вся загвоздка в слове necessary - устраивает ли тебя если в случае проблем с сетью половина строк обновится, а половина, нет

Или - готов ли ты поставить всю систему в интересную позу на продолжительное время блокировками на время обновления в одной транзакции и (если не срастется) повторять пока не получится

[belugin]

Цитата:

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

Или - готов ли ты поставить всю систему в интересную позу на продолжительное время блокировками на время обновления в одной транзакции и (если не срастется) повторять пока не получится

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

[Vadik]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

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

[fed]

Гм. Вы бы ссылочку на оригинальную тему дали, а то народ что-то ожесточенно обсуждает, а начала не видно...

[MikeR]

Цитата:

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

Гм. Вы бы ссылочку на оригинальную тему дали, а то народ что-то ожесточенно обсуждает, а начала не видно...

Я бы добавил : "сражается не на жизнь, а на смерть..."