Какой способ использование транзакции предпочтительнее.

[johny77]

Добрый день.

Имеется два способа использовать транзакцию. Вариант (А)

PHP код:

ttsbegin;
while(setEnumerator.moveNext())
{
    ...
    // выбор и обновление данных
}
ttscommit; 


Другой вариант (Б)

PHP код:

while(setEnumerator.moveNext())
{
    ttsbegin;
    ...
    // выбор и обновление данных
    ttscommit;
} 


Поскольку данные обновляются в одной транзакции, то вариант (А) предпочтительнее, поскольку откатывается вся транзакция.
В операторах ttsBegin/ttsCommit зашита дополнительная логика на уровне ядра системы, что тоже оставляет метод (А) более предпочтительным.

Некоторые разработчики используют метод (Б) аргументируя тем, что транзакция не блокирует базу. Но ведь как-то разносятся журналы ГК по 100 строк по разным модулям, накладные...

Может выбор должен зависить от магического алгоритма выбора и обновления данных. Но если алгоритм простой (выбор, клиента и обновление у него поля даже с обновлением глобальной адресной книги) считаю, что метод (А) предпочтительнее.

К какому методу склонны вы, обновление каких данных заставляло вас использовать метод (Б)?

[ice]

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

[S.Kuskov]

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

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

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

[Logger]

Еще есть компромиссный вариант, когда транзакция фиксируется не на каждом шаге цикла, а на каждую пачку записей, например по 100 штук. Позволяет снизить накладные расходы.

[dech]

У нас возникла проблема. Америкосский разработчик-интегратор внедрил свое решение, вследствие которого в системе расплодились дублирующие друг друга записи InventDim. Т.е. Все поля идентичны кроме InventDimId и RecId. Предстояла задача найти и устранить не только все дубликаты InventDim, но и заменить внешние ключи InventDimId по всем таблицам в системе. На выполнение подобной процедуры ушла неделя процессорного времени. Естественно, мы применили вариант (Б), т.к. при возникновении проблем (а проблемы были), не хотелось бы откатывать назад все изменения, которые уже произошли.