Gluk (Kazan)2 teras

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

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 по необходимости). Не хочу обсуждать, насколько такой подход был оправданным (по меньшей мере он был систематичным), но при наличии такого счетчика, можно было бы сделать тоже самое, но проще - по крайней мере исчезла бы необходимость иметь коммитящую версию.