Показать сообщение отдельно
Старый 03.07.2013, 15:22   #78  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от bodeaux Посмотреть сообщение
удалось установить, что в подобных случаях в таблице остается значение W = V + (-V + U_1) + (-V + U_2) + ... + (-V + U_n), где V - значение в точке point_0, U_i - значение, переданное в update номер i.
Надеюсь, кто-нибудь сможет пояснить, для чего заложена именно такая формула для Relative update, поскольку из предыдущего обсуждения мне показалось, что люди ожидали работы по формуле W = V + U_1 + U_2 + ... + U_n.
Relative Update предполагает именно относительное изменение значения поля. Т.е. эта возможность работает "логично", когда вам не важно прежнее значение, а важно лишь приращение. Если бы у вас был такой код (обратите внимание на инкремент вместо присваивания):
X++:
select forupdate t_1 where t_1.id == 5;
{// block_2
    select forupdate t_2 where t_2.id == 5;
    { // block_3
        select forupdate t_3 where t_3.id == 5;
        t_3.Val += 14; t_3.update();
    }
    t_2.Val += 700; t_2.update();
}
t_1.Val += 50000; t_1.update();
То все отработало бы так, как ожидается, правда?
Цитата:
Сообщение от bodeaux Посмотреть сообщение
В качестве офтопа еще хочу спросить, почему не возникает deadlock при выполнении block_2 после block_1.
Блокировки нужны для синхронизации параллельного доступа к одним и тем же записям, а тут все все выборки forupdate происходят в рамках одного соединения с БД, поэтому deadlock не возникает: в рамках одного соединения синхронизировать по определению нечего. Более интересный вопрос: почему при обновлении в случае оптимистичной конкурентной модели не возникает конфликт обновления после block_3. Ответ на этот вопрос можно найти в книге Inside Dynamics AX 2009:
Цитата:
...К счастью, среда времени выполнения Microsoft Dynamics AX управляет данной ситуацией. При исполнении оператора обновления среда времени выполнения находит все другие буфера записей, содержащие ту же запись, и если при этом они были извлечены с ключевым словом forupdate, то среда времени выполнения изменяет значение поля RecVersion данных буферов записей на новое значение из базы данных. Следовательно, второе обновление не вызовет ошибки.
То, что при обновлении с использованием одного из табличных буферов RecVersion обновляется во всех остальных табличных буферах в данном примере, можно убедиться под отладчиком.
За это сообщение автора поблагодарили: S.Kuskov (5).