Nikolay Ponomarenko wrote:
Кстати, а если абстрагироваться на более высокий уровень - хотя бы самого
соединения с БД и сокета - ведь для задачи ПАРАЛЛЕЛЬНОСТИ несколько
транзакций никак не применимы - все равно ведь они будут сериализованы,
пусть даже и на транспортном уровне, хотя конечно и уменьшат время реакции.
Идём читать букварь про одну транзакцию на коннект в многопоточных
приложениях, о начальник транспортного цеха ;)
Остается только случаи необходимости именно _транзакционности_ некоторых
7> псевдо-параллельных действий, так?
Нет (или может и да, что ты имел в виду под псевдо, я не въехал),
остаются вопросы:
а) Приложений, построенных не на модальных от начала до конца форточках.
бе) Элементарного удобства локализации транзакций в функциональных
модулях, а не прыгания как вокруг ёлки вокруг одного датамодуля.
ве) Редактирования и коммита в вызываемых модулях и использование
проделанных модификаций в вызывающих без перечитывания ВСЕГО. Например,
ввод клиента в процессе ввода счёта. Можно и в одной, но замумукашься в
боле-мене сложном структурно функционале отслеживать в каком состоянии
была единственная транзакция на входе в модуль и надо ли её коммитить на
выходе и как откатить изменения функции не откатывая изменений в
вызвавшей её функции и во всех вызванных из неё ранее.
ге) Пессимистическая блокировка сложных кустовых структур с
необходимостью коммить/роллбачить действительно модифицирующие
транзакции на объектах внутри этой структуры.
Это просто первое что пришло в голову из того, что мы имеем. Это как
щастье - понимаем, что оно было, только когда его уже нет :)
ЗЫ Материться в приличном обществе без веской на то причины не следует
даже в нецитируемой подписи.
--
Regards. Ded.
