Коллеги, что вы думаете о данном коде? 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 - согласен.

[belugin]

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

[Vadik]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

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

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

[fed]

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

[belugin]

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

[MikeR]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

[Vadik]

Цитата:

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

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

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

[MikeR]

Цитата:

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

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

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

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