2 teras
Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.
Это, простите, какая-то чушь.
Вы, похоже, непонимаете, что изоляция - это защита (требуемого уровня) исполняемой транзакции от изменений во внешнем мире, а вовсе не защита внешнего мира от изменений в транзакции.
Фраза "ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой" в корне не верна. Запустите рядом транзакцию в Dirty Read - и ей будут видны еще незакомиченные изменения. Запустите рядом транзакцию в Serializable - и ей не будут видны даже и закомиченные.

Вот, что пишет по этому поводу 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.
Что я могу ответить... Не читайте википедию.
По поводу того, что родительская транзакция в принципе не может смотреть на изменения дочерней - SergSuper уже написал. Только дочерняя может пытаться смотреть на изменения родительской. А раз уж "child's lock wins", то и вообще не нужны никакие блокировки между родительской и дочерней (ну либо в дэдлок войдём на ровном месте).

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

Знаете, я как-то администрировал достаточно крупное приложение на oracle 7.3. ... Так вот - в нем каждая процедура была представлена в двух ипостасях - some_proc и some_proc_nc. Где some_proc, очевидно, вызывала some_proc_nc и commit. ... можно было бы сделать тоже самое, но проще - по крайней мере исчезла бы необходимость иметь коммитящую версию.
Сделать проще можно было бы - именно через полноценные вложенные транзакции. Процедура имеет вначале Begin Trans, в конце Commit Trans (или Rollback, по ситуации), вызывай её откуда хочешь, и никакого геморроя со счетчиками невнятными. В аксесе я именно так и поступал, горя не знал.
Но Вы то говорили про майкрософтовскую реализацию, которая к вложенным транзакциям не имеет никакого отношения, и работу со вложенными Begin/Commit/Rollback ничуть не упрощает, а только усложняет. Т.е. можно в начале процедуры проверять счетчик, и в зависимости от его значения либо сейвпоинт ставить, либо транзакцию открывать, при успешном завершении процедуры либо ничего не делать (если был сейвпоинт), либо коммитить транзакцию (если была транзакция), а при неуспешном завершении либо откатывать до сейвпоинта (если он был), либо откатывать транзакцию. Но это - увеличение геморроя, а вовсе не его уменьшение.

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

2 softwarer
Еще раз. Для меня нонсенс - вообще желание менять уровни внутри одной транзакции, независимо от того, в какую сторону.
А для Вас вообще желание менять уровни изоляции (не внутри еще какой-нибудь, а просто так) - не является ли нонсенсом?
Ну т.е. открыли соединение, запустили пачку каких-нибудь одиночных (нетранзакционных) select/insert/update/delete, на каком уровне изоляции - хз, на каком-то умолчальном, потом начали транзакцию с уровнем изоляции А, что-то там сделали, закоммитились, начали транзакцию с уровнем изоляции B, что-то там сделали, закоммитились, начали транзакцию с уровнем изоляции C, что-то сделали, закоммитились...
Эта последовательность действий - нонсенс (для Вас), или нет?
Если нет, то почему та же самая последовательность действий превращается в нонсенс как только её оборачиваем в транзакцию?
Если да, то выходит, что по хорошему надо вообще запретить менять уровень изоляции. Как один какой-то уровень изоляции выставили, так с ним и работают. Причем все. Выставили всем сериалайзбл, и все довольны :).

По поводу того, что родительская транзакция в принципе не может смотреть на незакомиченные изменения дочерней - SergSuper уже написал. Только дочерняя может пытаться смотреть на незакомиченные изменения родительской.
так корректнее.

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

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

Gluk (Kazan)Sorry, теперь включился
На мой взгляд будет каша если реализовывать вложенные транзакции именно в такой форме.
Пардон, в чём каша то?
Rollback откатывает всё, что было сделано между Begin и Rollback, и ничего больше не трогает.
Имхо - абсолютно логичное поведение было бы, если бы оно было таким.
Почему такая конструкция не должна откатить что-то внутри - не понимаю.
Почему такая конструкция должна откатывать что-то снаружи - не понимаю тем более.

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

Хотя ИМХО было бы более правильно оформлять эту "маленькую зелёненькую пирамидку" именно как отдельную самую обычную транзакцию, просто со необычным уровнем изоляции - "изолирована от всего, за исключением одной отдельно взятой рядом исполняющейся транзакции".

2 Gluk (Kazan)
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает
Не вызывает.
То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает. То, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает.
Я как бы ни с чем и не спорю.
Просто если "маленькая зелёненькая пирамидка" по факту является независимой транзакцией со специфичным уровнем изоляции - то я бы предпочёл называть её именно независимой транзакцией со специфичным уровнем изоляции. Если её называют по другому - ничего страшного, главное не запутаться.
Если она по факту является чем-то другим - ну значит мои рассуждения на тему "как бы это покрасивше назвать" можно выкинуть в помойку, я не обижусь.

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

Если объединить "частичный" откат с "условным" коммитом - получится вполне съедобная вложенная транзакция.
Но у MS (в MS SQL Server) половина функционала (а именно условный коммит) - оставлена на Commit'е, а вторая половина (а именно частичный ролбек) - перекочевала в сейвпойнты.
В итоге получилась полная херня.

Самое непонятное, что эти же люди сделали Access, где "условный" Commit вполне нормально сосуществует с "частичным" Rollback.
(предлагаю воздержаться от оффтопа на тему Вашего неверия в существование транзакций в аксесе )

Gluk (Kazan) Пьяный Лох
То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает.

Вот это вызывает вопросы. И в Oracle этого нет
Как это? Оракл не умеет две транзации исполнить? Скажите, что Вы пошутили :)

2 Gluk (Kazan)
Пьяный ЛохНеобходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны.

Вызывает. Очень сильно вызывает :(
А почему?
Вам так сильно хочется писать код в стиле упомянутого на прошлой странице, т.е.

Мне лично такое вовсе не нужно. Писать больше, думать потом еще, где какую вызвать... Ну его в пень.
Программист - животное ленивое.
Я вполне буду доволен, если смогу один раз написать
и использовать эту процедурину там, где мне она нужна, а уж об уровнях вложенности пусть сервер думает, у него голова большой.
Собственно, в MS SQL Server я именно так и могу сделать. Я не могу безбоязненно в эту процедурину Rollback запихнуть :)

не то процитировал :(

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


вот это ВЫЗЫВАЕТ вопросы
Но ведь автономная транзакция имеет доступ к измененным, но, разумеется, еще незакомеченным данным "родительской"? Или я не прав?