Вам необходимо более четко определить ваши требования.«Вложенные транзакции» неоднозначны.Это может означать просто приостановку одной транзакции для запуска другой, а затем возобновление первой:
transactionManager.begin();
// now in tx A
transaction txA = transactionManager.suspend();
// no tx active here
transactionManager.begin();
// now in tx B
transactionManager.commit(); // tx B ends
// no tx active here
transactionManager.resume(txA);
// now in tx A again
transactionManager.commit(); // tx A ends
Это обычная ситуация, когда вам необходимо выполнить некоторую операцию, например обновление журнала аудита, которое логически отделено от внешнегосделка.Любой менеджер транзакций сделает это, хотя редко пишется код, который напрямую управляет TM.Вместо этого используйте контейнер EJB.
Тогда у вас есть случай, когда вы просто хотите, чтобы псевдо-вложение упростило структурирование логики:
// no tx active at start
transactionManager.begin();
// tx A now active, nesting count = 1
transactionManager.begin();
// tx A still active, nesting count = 2
transactionManager.commit();
// nullop, tx A still active, nesting count = 1
transactionManager.commit();
// tx A really committed, no tx active, count = 0.
На первый взгляд это выглядит привлекательно, но вызывает больше хлопотчем это стоит, когда происходит вложенный откат.Широко не поддерживается, хотя некоторые базы данных позволяют это сделать обработку хранимых процедур проще.
Наконец, у вас есть истинные вложенные транзакции, в которых субтранзакция наследует блокировки от своего родителя и передает свои собственные блокировки этому родителю по завершении
transactionManager.begin();
// now in tx A1
transactionManager.begin();
// now in tx A1.1
// can see uncommitted changes made by A1
transactionManager.commit(); // validate ability to make A1.1 changes permanent, but do not actually do so yet
// now in tx A1, still holding locks from A1.1 also
transactionManager.commit(); // commit A1 and A1.1 changes atomically.
Это полезно главным образом для изоляции отказов - можно откатить субтранзакцию и сделать что-то другое, не оказывая влияния на внешнюю транзакцию.Это очень мощная модель транзакций.Это также сложно реализовать - в настоящее время это поддерживает только JBossTS.Не то чтобы это принесло вам большую пользу в большинстве случаев использования Java EE, так как никакой менеджер ресурсов, то есть база данных или очередь сообщений, не поддерживает его.
Что касается MVCC, это вообще не имеет ничего общего с менеджером транзакций.Ваши бизнес-данные хранятся в менеджере ресурсов, обычно в реляционной базе данных.Модель, которую RM использует для обеспечения изоляции передачи и управления параллелизмом, ортогональна тому, как управляется транзакция.Oracle и postgres предпочитают MVCC, в то время как некоторые другие базы данных предпочитают блокировку на уровне таблицы, страницы или строки.Менеджер транзакций не знает или не заботится.