Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 hvlad
Они позволяют откатывать часть тр-ции. Как и нормальные сейвпойнты.

Каким образом оно откатит "часть", позвольте полюбопытствовать?
Русским по белому же сказано:
It is not legal for the transaction_name parameter of a ROLLBACK TRANSACTION statement to refer to the inner transactions of a set of named nested transactions. transaction_name can refer only to the transaction name of the outermost transaction.


-------------

2 Gluk (Kazan)
Я тоже в курсе Ваших заблуждений, так что продолжайте упорствовать :)
27 сен 07, 14:45    [4724521]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Пьяный Лох
Русским по белому же сказано:
[quot ]It is not legal for the transaction_name parameter of a ROLLBACK TRANSACTION statement to refer to the inner transactions of a set of named nested transactions. transaction_name can refer only to the transaction name of the outermost transaction.



Более того:

Naming multiple transactions in a series of nested transactions with a transaction name has little effect on the transaction. Only the first (outermost) transaction name is registered with the system. A rollback to any other name (other than a valid savepoint name) generates an error. None of the statements executed before the rollback is, in fact, rolled back at the time this error occurs. The statements are rolled back only when the outer transaction is rolled back.
27 сен 07, 15:06    [4724778]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
Gluk (Kazan)
2 teras

Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахар
Пожалуй, я неудачно выразился. Имеется в виду владелец блокировок. Каждая транзакция удерживает набор блокировок. В случае с savepoint - все блокировки получаются от имени одной транзакции. В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией. Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой.
Насчет MS SQL не знаю - не пользую. Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах.
27 сен 07, 15:52    [4725277]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
teras
Gluk (Kazan)
2 teras

Что есть домен блокировок ? В MS SQL 2000 вложенный Begin Transaction не более чем синтаксический сахар
Пожалуй, я неудачно выразился. Имеется в виду владелец блокировок. Каждая транзакция удерживает набор блокировок. В случае с savepoint - все блокировки получаются от имени одной транзакции. В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией. Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой.
Насчет MS SQL не знаю - не пользую. Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах.


Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ?
27 сен 07, 15:59    [4725343]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 teras
В случае с nested transaction - вложенная транзакция наследует все блокировки родителя, но новые блокировки получаются уже вложенной транзакцией.

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

Причем две транзакции, даже вложенные в одну и ту же объемлющую, конкурируют между собой.

А это вообще как?
Если две транзакции вложены в третью, но не вложены друг в друга - то они исполняются последовательно. К тому моменту, как начинается вторая - первая уже завершена, и какие-либо специфические блокировки (отличные от "родительских") все сняты, даже если они были. Как транзакции могут между собой конкурировать, если они по времени не пересекаются?

Насчет MS SQL не знаю - не пользую.

А что пользуете?
Т.е. присоединяюсь к вопросу - это абстрактные рассуждения или нет?

Судя по MSDN, это просто счетчик, позволяющий не заботится о необходимости расстановки begin trans/commit trans в процедурах.

Совсем гениально.
Вложенные begin trans/commit trans - позволяют не заботиться о расстановке begin trans/commit trans?
Хлопаю одной ладонью.
27 сен 07, 16:49    [4725837]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Dmitry Arefiev пишет:
> сохранения (savepoint) это:
> 1) одно и то же, но названное по разному;
> 2) или существуют принципиальные факты различий в их поведении.

Почти одно и тоже. Разница только в том, что во вложенных
транзакциях нельзя откатить транзакцию частично, а при наличии
savepoint - можно.

Posted via ActualForum NNTP Server 1.4

27 сен 07, 16:50    [4725854]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

hvlad пишет:
> Транзакция или вся выполняется, или вся не выполняется. Всё остальное -
> не транзакция

Это классическая ACID-транзакция. Мы вроде бы говорим о двух ее расширениях.

Posted via ActualForum NNTP Server 1.4

27 сен 07, 16:53    [4725883]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

teras пишет:
> заключается в том, что вложенные транзакции позволяют образуют
> независимый собственный домен блокировок, в то время, как точки

В определении моделей транзакций про блокировки ничего нет,
потому как это уже реализация, а не модель.

Posted via ActualForum NNTP Server 1.4

27 сен 07, 16:56    [4725920]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
MasterZiv
Разница только в том, что во вложенных
транзакциях нельзя откатить транзакцию частично

Давайте называть кошку кошкой.
Транзакцию вообще нельзя откатить частично. Если какие-то изменения были - то они были все. Вложенные транзакции (в нормальном, а не майкрософтовском понимании этого слова) затем и нужны, чтобы оформленной во вложенную транзакцию единицы работы - не было (при откате). То, что эту функциональность урезали и обозвали словом "сейвпоинт", а вложенной транзакцией обозвали какую-то белиберду, которую даже откатить нельзя - это п....ц какая заслуга майкрософта. Но не стоит за ними эту фигню повторять.
27 сен 07, 17:03    [4726005]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9993
MasterZiv
во вложенных
транзакциях нельзя откатить транзакцию частично, а при наличии
savepoint - можно

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

Играя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ... Но их нет в природе ... А потому апельсин может быть соленым.
27 сен 07, 17:11    [4726089]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Если использовать несуществующие-в-природе вложенные транзакции

Я категорически протестую против использования слов "несуществующие в природе" :)
Существующие, еще как существующие.
27 сен 07, 17:16    [4726122]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Dmitry Arefiev
Играя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ...

Я уже назвал еще одно отличие.
Вложенная транзакция - она в первую очередь транзакция, а уж потом вложенная.
Т.к. она транзакция - она может быть использована как самостоятельная единица. Сама, **я, без ансамбля. Завернули транзакцию в процедуру, вызвали её - получили нормальную, вполне обычную транзакцию. Вызвали эту же процедуру внутри другой транзакции - нормальная транзакция превратилась во вложенную.
А вот сейвпоинт - сам по себе использован быть не может. Он "чисто внутренний".
27 сен 07, 17:20    [4726164]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох
Dmitry Arefiev
Играя в эти слова сложно найти отличия, разве что вложенная транзакция, теоретически, может усилить уровень изолированности ...

Я уже назвал еще одно отличие.
Вложенная транзакция - она в первую очередь транзакция, а уж потом вложенная.
Т.к. она транзакция - она может быть использована как самостоятельная единица. Сама, **я, без ансамбля. Завернули транзакцию в процедуру, вызвали её - получили нормальную, вполне обычную транзакцию. Вызвали эту же процедуру внутри другой транзакции - нормальная транзакция превратилась во вложенную.
А вот сейвпоинт - сам по себе использован быть не может. Он "чисто внутренний".


То чего хотите есть у нас. Только называется по другому - автономная транзакция.
Удобный способ получения deadlock-а в рамках одной сессии

P.S. До завтра
27 сен 07, 17:25    [4726209]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Gluk (Kazan)
То чего хотите есть у нас. Только называется по другому - автономная транзакция.

Это разные вещи.
27 сен 07, 17:28    [4726245]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67390
Блог
Dmitry Arefiev
Возник спор - вложенные транзакции (nested transaction) и точки сохранения (savepoint) это:
1) одно и то же, но названное по разному;
2) или существуют принципиальные факты различий в их поведении.

Я бы сказал, это похожие вещи с важным синтаксическим отличием, обуславливающим и отличие в поведении.

Для начала стоит определиться с тем, что есть вложенная транзакция. Для этого, с моей точки зрения, есть простой и удачный пример. Допустим, у нас есть классическая бизнес-функция перекладывания некоторой суммы со счета А на счет Б. Как мы понимаем, это транзакция, состоящая, условно, из start transaction [может быть неявного], пары update-ов и commit-а. Теперь: предположим, мы хотим реализовать бизнес-функцию "оплаты с комиссией", суть которой в том, что со счета А идет некая сумма на счет Б и 1% от этой суммы на счет В. Опять же мы понимаем, что это транзакция, и в то же время понимаем, что по сути это два вызова уже реализованной подпрограммы - вот мы и дошли до транзакции, состоящей из двух вложенных транзакций.

Итого: при соответствующем синтаксисе вложенных транзакций мы можем взять любую операцию, являющуюся "обычной транзакцией" и использовать ее как вложенную, то есть как часть другой транзакции. С сейвпоинтами мы такого не можем, поскольку синтаксис у них заведомо другой. Это, с моей точки зрения, есть основное отличие. Конечно, в конкретной реализации "вложенным транзакциям" могут дать другой, несовместимый синтаксис, но это будет довольно странно, имхо.

Можно, наверное, накопать и еще мелочей. Скажем, скрипт

create table svp as select rownum n from dual connect by level <= 1;
savepoint s;
update svp set n = 2;
savepoint s;
update svp set n = 3;
savepoint s;
update svp set n = 4;
rollback to savepoint s;
select n from svp;
rollback to savepoint s;
select n from svp;
rollback to savepoint s;
select n from svp;

поведет себя не совсем так, как я ожидал бы от вложенных транзакций.
27 сен 07, 17:39    [4726358]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9993
Пьяный Лох
Это разные вещи.

Совершенно разные.

А то, что вы мне предлагаете попробовать сделать при помощи "самостоятельной единицы" транзакции, так это уже не вложенная транзакция ...

Дискусии - большое спасибо, все прояснил для себя ! :)
27 сен 07, 17:40    [4726369]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Dmitry Arefiev
А то, что вы мне предлагаете попробовать сделать при помощи "самостоятельной единицы" транзакции, так это уже не вложенная транзакция ...

Вы про что? Что именно я предлагаю попробовать сделать?
27 сен 07, 18:21    [4726650]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9993
softwarer
поскольку синтаксис у них заведомо другой. Это, с моей точки зрения, есть основное отличие.

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

Вам как дельфийцу, может быть интересна отправная точка обсуждения :) Два варианта:

oTX.BeginTransaction; // стартует транзакцию
try
  ....
  oTX.BeginTransaction; // создает savepoint
  try
    ...
    oTX.Commit; // делает release savepoint
  except
    oTX.Rollback; // делает rollback to savepoint
    raise;
  end;
  oTX.Commit; // делает commit транзации
except
  oTX.Rollback; // делает rollback тразанции
  raise;
end;

и другой ...

oTX.BeginTransaction; // стартует транзакцию
try
  ....
  oTX2 := oTX.BeginTransaction; // создает savepoint
  try
    ... << B
    oTX2.Commit; // делает release savepoint
  except
    oTX2.Rollback; // делает rollback to savepoint
    raise;
  end;
  oTX.Commit; // делает commit транзации
except
  oTX.Rollback; // делает rollback тразанции
  raise;
end;

Второй вариант предполагает наличие самостоятельных, вложенных транзакций. И тут возникает элементарная ситуация. Вот код в точке B берет и делает oTX.Commit/Rollback - т.е. завершает корневую транзакцию. Тогда все oTXi становятся инвалидными. И обращение к ним ведет к exception, а без них логика в полный рост не работает ...

Собственно я за схему (1). Коли имеется природа стека, то пусть такой и объектная модель и поведение будут.
27 сен 07, 19:46    [4726981]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67390
Блог
Dmitry Arefiev
может быть то, что вложенные транзакции могут усилить уровень изоляции.

Вот это как раз очень спорный момент. Насколько я знаю, в некоторых серверах существует возможность менять уровень изоляции внутри транзации, но с моей точки зрения это - нонсенс. Вызвано это, насколько я понимаю, сугубо прикладными причинами (желанием прочитать в dirty read нечто, оставив остальной транзакции возможность работать в нормальном режиме) и желательно придумать более культурные пути решения тех же проблем. Ну а вложенная транзакция - как ни крути, "внутри", так что тоже получается некий нонсенс.

Вообще, вопрос изоляции в серверах, с моей точки зрения, недостаточно проработан. В частности, с моей точки зрения, для ХП необходим некий constraint типа "на каком уровне изоляции она может использоваться" - поскольку очевидно, что вызов на неподходящем уровне может привести к большим неприятностям.

Dmitry Arefiev
В остальном, хоть убейте, но логической разницы не вижу. Лишь - разные термины, разный синтаксис ...

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

Это технически разные механизмы со своими особенностями. Скажем, простой пример: если я из формы А вызываю форму Б, форма Б может обеспечивать возможность "частичного отката" как тем, так и другим механизмом. Однако, механизм вложенных транзакций подразумевает, что при нажатии OK форма Б закрывается, а с сейвпоинтами я могу сделать нечто вроде Apply (сохранить и продолжить редактирование). Пример конечно условный, но показывает "практическую разницу".

Dmitry Arefiev
Вам как дельфийцу, может быть интересна отправная точка обсуждения
.....
Собственно я за схему (1). Коли имеется природа стека, то пусть такой и объектная модель и поведение будут.

Мне как дельфийцу ни один из этих вариантов особо не нравится.

В первую очередь, серверные концепции и доступ к ним из API - несколько разные вещи. Далее, мне как дельфийцу нужно следующее:

1. Возможность писать код в парадигме используемого сервера, не думая о специфике API. Если я коннекчусь к Oracle - я хочу иметь возможность написать start transaction / savepoint / savepoint / rollback to savepoint / savepoint / commit так, чтобы это выполнилось в точности так же, как непосредственная отправка таких команд на сервер.

2. Аккуратные, подчеркнуто отделенные обобщающие парадигмы API, которые я могу использовать по своему желанию и которые имеют инкапсулирванно разную реализацию для разных серверов. При этом они должны быть очень тщательно продуманы на отсутствие конфликтов с предыдущим пунктом.

Ну а имеющаяся природа стека далеко не так проста и однозначна.

Connected to Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 
Connected as test

SQL> create table svp as select 0 n from dual;

Table created

SQL> savepoint s0;

Savepoint created

SQL> update svp set n = 1;

1 row updated

SQL> savepoint s1;

Savepoint created

SQL> update svp set n = 2;

1 row updated

SQL> savepoint s0;

Savepoint created

SQL> update svp set n = 3;

1 row updated

SQL> savepoint s2;

Savepoint created

SQL> update svp set n = 4;

1 row updated

SQL> rollback to savepoint s0;

Rollback complete

SQL> select n from svp;

         N
----------
         2

SQL> rollback to savepoint s2;

rollback to savepoint s2

ORA-01086: savepoint 'S2' never established

SQL> rollback to savepoint s0;

Rollback complete

SQL> select n from svp;

         N
----------
         2

SQL> rollback to savepoint s1;

Rollback complete

SQL> rollback to savepoint s0;

rollback to savepoint s0

ORA-01086: savepoint 'S0' never established

Как видите, тут как бы это выразиться, не совсем стек.
27 сен 07, 20:27    [4727092]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 softwarer
Вызвано это, насколько я понимаю, сугубо прикладными причинами (желанием прочитать в dirty read нечто, оставив остальной транзакции возможность работать в нормальном режиме)

А почему Вы не рассмотрели обратную ситуацию - когда хочется "вложенную" часть выполнить на более высоком уровне изоляции? Тогда и "нонсенс внутри" не совсем нонсенс, и озвученная проблема "на каком уровне изоляции ХП может исполняться" не совсем проблема - ХП просто себе выставит нужный ей уровень, отработает, и преспокойно закоммитится.
27 сен 07, 20:41    [4727122]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
teras
Member

Откуда:
Сообщений: 293
Gluk (Kazan)
Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ?
И то и другое. Собственно, вопрос ведь вначале прозвучал абстрактно, так и отвечал. Сама модель - следствие чтения описаний алгоритмов, таких, как ARIES/NT и т.п. Что касается практики, то такой подход точно реализован в BDB, и, кроме, того встречался в документации на другие продукты.

MasterZiv
В определении моделей транзакций про блокировки ничего нет, потому как это уже реализация, а не модель.
Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.

Пьяный Лох
Для всего остального мира эти две транзакции неотличимы (собственно, они обязаны выглядеть как одна, внешняя), а внутри - родительской транзакции нет смысла конкурировать с дочерней, равно как и наоборот, ибо ни к чему хорошему такая конкуренция не приведет, за исключением возможности дэдлока транзакции со своими собственными внутренностями.
Вот, что пишет по этому поводу wikipedia: Changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed.
Или здесь: A parent transaction's actions are considered to conflict with its child's actions but not vice versa. Thus, it cannot access a resource if a child's lock prohibits the access. Thus, the child's lock wins.
Вот например, одно большое отличие в блокировщике - отпускание разделяемых блокировок до завершения родительской транзакции.

Пьяный Лох
Если две транзакции вложены в третью, но не вложены друг в друга - то они исполняются последовательно. К тому моменту, как начинается вторая - первая уже завершена, и какие-либо специфические блокировки (отличные от "родительских") все сняты, даже если они были. Как транзакции могут между собой конкурировать, если они по времени не пересекаются?
Очень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении. Простейший пример - та же BDB.

Пьяный Лох
Совсем гениально.
Вложенные begin trans/commit trans - позволяют не заботиться о расстановке begin trans/commit trans?
Знаете, я как-то администрировал достаточно крупное приложение на oracle 7.3. Один из основных лозунгов у них был: "пишем всё на PL/SQL". Так вот - в нем каждая процедура была представлена в двух ипостасях - some_proc и some_proc_nc. Где some_proc, очевидно, вызывала some_proc_nc и commit. А некотрые процедуры еще и принимали специальный флаг, в зависимости от которого вызывали some_proc или some_proc_nc (и commit по необходимости). Не хочу обсуждать, насколько такой подход был оправданным (по меньшей мере он был систематичным), но при наличии такого счетчика, можно было бы сделать тоже самое, но проще - по крайней мере исчезла бы необходимость иметь коммитящую версию.
27 сен 07, 20:53    [4727158]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67390
Блог
Пьяный Лох
А почему Вы не рассмотрели обратную ситуацию - когда хочется "вложенную" часть выполнить на более высоком уровне изоляции?

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

Пьяный Лох
и озвученная проблема "на каком уровне изоляции ХП может исполняться" не совсем проблема - ХП просто себе выставит нужный ей уровень, отработает, и преспокойно закоммитится.

Насколько я понимаю, вложенные транзакции в MSSQL в значительной степени аргументируются именно этой возможностью.

Однако, это всего лишь заметание мусора под кровать. Вместо "бардака внутри ХП" будет "бардак в вызывающем коде", разницы не особо.
27 сен 07, 21:07    [4727199]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9993
softwarer

Я тут погуляв с собакой, увидел проблемы и в своих и в ваших рассуждениях.
Короче, буду думать - что-то все не слишком однозначно с API.
27 сен 07, 21:33    [4727246]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67390
Блог
Dmitry Arefiev
Короче, буду думать - что-то все не слишком однозначно с API.

Я бы предложил еще и обсудить в форуме дельфы или возможно в личной переписке с избранными :) Это действительно непростой вопрос, подойти к которому стоит очень аккуратно.
27 сен 07, 21:56    [4727284]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
teras
вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.

Это как это? Как может родительская транзакция смотреть на вложенную в неё? Т.е. мы имеем такую последовательность
- Родительская транзакция
- Некие действия 1
- - Вложенная транзакция
- - Некие действия 2
- - Конец вложенной транзакции
- Некие действия 3
- Конец родительской транзакции

В каком месте тут родительская транзакция может смотреть на вложенную? Может Вы путаете с автономными транзакциями?
teras
Очень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении.

Т.е. в одном транзакции может паралельно работать несколько потоков? Тогда это не будет транзакцией
27 сен 07, 23:51    [4727501]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить