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

[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;//слияние к предку

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

[Link]

Цитата:

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

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

По аналогии: Зачем делать бэкапы? Винчестеры довольно надежные, ломаются очень редко, вероятность отказа меньше 5%. А так экономия времени, места и админу проще

[belugin]

Цитата:

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

На практике это менее 5 процентов.

То есть каждая 20 транзакция ломает данные и это ок?

[MikeR]

Скажем так, я переделал - работать стало ЗНАЧИТЕЛЬНО быстрее, сбоев не было вообще, проценты - это оценочное суждение

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