解惑 spring 嵌套事务

解惑 spring 嵌套事务

/**
  * @author 王政
  * @date 2006-11-24
  * @note 转载请注明出处
  */

   在所有使用 spring 的应用中, 声明式事务管理可能是使用率最高的功能了, 但是, 从我观察到的情况看,
绝大多数人并不能深刻理解事务声明中不同事务传播属性配置的的含义, 让我们来看一下 TransactionDefinition 接口中的定义

/**
	 * Support a current transaction, create a new one if none exists.
	 * Analogous to EJB transaction attribute of the same name.
	 * <p>This is typically the default setting of a transaction definition.
	 */
	int PROPAGATION_REQUIRED = 0;

	/**
	 * Support a current transaction, execute non-transactionally if none exists.
	 * Analogous to EJB transaction attribute of the same name.
	 * <p>Note: For transaction managers with transaction synchronization,
	 * PROPAGATION_SUPPORTS is slightly different from no transaction at all,
	 * as it defines a transaction scopp that synchronization will apply for.
	 * As a consequence, the same resources (JDBC Connection, Hibernate Session, etc)
	 * will be shared for the entire specified scope. Note that this depends on
	 * the actual synchronization configuration of the transaction manager.
	 * @see org.springframework.transaction.support.AbstractPlatformTransactionManager#setTransactionSynchronization
	 */
	int PROPAGATION_SUPPORTS = 1;

	/**
	 * Support a current transaction, throw an exception if none exists.
	 * Analogous to EJB transaction attribute of the same name.
	 */
	int PROPAGATION_MANDATORY = 2;

	/**
	 * Create a new transaction, suspend the current transaction if one exists.
	 * Analogous to EJB transaction attribute of the same name.
	 * <p>Note: Actual transaction suspension will not work on out-of-the-box
	 * on all transaction managers. This in particular applies to JtaTransactionManager,
	 * which requires the <code>javax.transaction.TransactionManager</code> to be
	 * made available it to it (which is server-specific in standard J2EE).
	 * @see org.springframework.transaction.jta.JtaTransactionManager#setTransactionManager
	 */
	int PROPAGATION_REQUIRES_NEW = 3;

	/**
	 * Execute non-transactionally, suspend the current transaction if one exists.
	 * Analogous to EJB transaction attribute of the same name.
	 * <p>Note: Actual transaction suspension will not work on out-of-the-box
	 * on all transaction managers. This in particular applies to JtaTransactionManager,
	 * which requires the <code>javax.transaction.TransactionManager</code> to be
	 * made available it to it (which is server-specific in standard J2EE).
	 * @see org.springframework.transaction.jta.JtaTransactionManager#setTransactionManager
	 */
	int PROPAGATION_NOT_SUPPORTED = 4;

	/**
	 * Execute non-transactionally, throw an exception if a transaction exists.
	 * Analogous to EJB transaction attribute of the same name.
	 */
	int PROPAGATION_NEVER = 5;

	/**
	 * Execute within a nested transaction if a current transaction exists,
	 * behave like PROPAGATION_REQUIRED else. There is no analogous feature in EJB.
	 * <p>Note: Actual creation of a nested transaction will only work on specific
	 * transaction managers. Out of the box, this only applies to the JDBC
	 * DataSourceTransactionManager when working on a JDBC 3.0 driver.
	 * Some JTA providers might support nested transactions as well.
	 * @see org.springframework.jdbc.datasource.DataSourceTransactionManager
	 */
	int PROPAGATION_NESTED = 6;

我们可以看到, 在 spring 中一共定义了六种事务传播属性, 如果你觉得看起来不够直观, 那么我来转贴一个满大街都有的翻译

引用

PROPAGATION_REQUIRED -- 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS -- 支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY -- 支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW -- 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED -- 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER -- 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED -- 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。
前六个策略类似于EJB CMT，第七个（PROPAGATION_NESTED）是Spring所提供的一个特殊变量。
它要求事务管理器或者使用JDBC 3.0 Savepoint API提供嵌套事务行为（如Spring的DataSourceTransactionManager）

在我所见过的误解中, 最常见的是下面这种:

引用

假如有两个业务接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一个方法实现如下

/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
// 调用 ServiceB 的方法
ServiceB.methodB();
}

那么如果 ServiceB 的 methodB  如果配置了事务, 就必须配置为 PROPAGATION_NESTED

这种想法可能害了不少人, 认为 Service 之间应该避免互相调用, 其实根本不用担心这点，PROPAGATION_REQUIRED 已经说得很明白,
如果当前线程中已经存在事务, 方法调用会加入此事务, 果当前没有事务，就新建一个事务, 所以 ServiceB#methodB() 的事务只要遵循最普通的规则配置为 PROPAGATION_REQUIRED 即可, 如果 ServiceB#methodB (我们称之为内部事务, 为下文打下基础) 抛了异常, 那么 ServiceA#methodA(我们称之为外部事务) 如果没有特殊配置此异常时事务提交 (即 +MyCheckedException的用法), 那么整个事务是一定要 rollback 的, 什么 Service 只能调 Dao 之类的言论纯属无稽之谈, spring 只负责配置了事务属性方法的拦截, 它怎么知道你这个方法是在 Service 还是 Dao 里 ?

     说了这么半天, 那到底什么是真正的事务嵌套呢, 解释之前我们来看一下  Juergen Hoeller 的原话

Juergen Hoeller 写道

PROPAGATION_REQUIRES_NEW starts a new, independent "inner" transaction for the given scope. This transaction will be committed or rolled back completely independent from the outer transaction, having its own isolation scope, its own set of locks, etc. The outer transaction will get suspended at the beginning of the inner one, and resumed once the inner one has completed.

Such independent inner transactions are for example used for id generation through manual sequences, where the access to the sequence table should happen in its own transactions, to keep the lock there as short as possible. The goal there is to avoid tying the sequence locks to the (potentially much longer running) outer transaction, with the sequence lock not getting released before completion of the outer transaction.

PROPAGATION_NESTED on the other hand starts a "nested" transaction, which is a true subtransaction of the existing one. What will happen is that a savepoint will be taken at the start of the nested transaction. íf the nested transaction fails, we will roll back to that savepoint. The nested transaction is part of of the outer transaction, so it will only be committed at the end of of the outer transaction.

Nested transactions essentially allow to try some execution subpaths as subtransactions: rolling back to the state at the beginning of the failed subpath, continuing with another subpath or with the main execution path there - all within one isolated transaction, and not losing any previous work done within the outer transaction.

For example, consider parsing a very large input file consisting of account transfer blocks: The entire file should essentially be parsed within one transaction, with one single commit at the end. But if a block fails, its transfers need to be rolled back, writing a failure marker somewhere. You could either start over the entire transaction every time a block fails, remembering which blocks to skip - or you mark each block as a nested transaction, only rolling back that specific set of operations, keeping the previous work of the outer transaction. The latter is of course much more efficient, in particular when a block at the end of the file fails.

Juergen Hoeller 写道

Rolling back the entire transaction is the choice of the demarcation code/config that started the outer transaction.

So if an inner transaction throws an exception and is supposed to be rolled back (according to the rollback rules), the transaction will get rolled back to the savepoint taken at the start of the inner transaction. The immediate calling code can then decide to catch the exception and proceed down some other path within the outer transaction.

If the code that called the inner transaction lets the exception propagate up the call chain, the exception will eventually reach the demarcation code of the outer transaction. At that point, the rollback rules of the outer transaction decide whether to trigger a rollback. That would be a rollback of the entire outer transaction then.

So essentially, it depends on your exception handling. If you catch the exception thrown by the inner transaction, you can proceed down some other path within the outer transaction. If you let the exception propagate up the call chain, it's eventually gonna cause a rollback of the entire outer transaction.

    也就是说, 最容易弄混淆的其实是 PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED, 那么这两种方式又有何区别呢? 我简单的翻译一下 Juergen Hoeller 的话 :
   
    PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行.


    另一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务,  它是已经存在事务的一个真正的子事务. 潜套事务开始执行时,  它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交.

    由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 潜套事务也会被 commit, 这个规则同样适用于 roll back.
   
   
    那么外部事务如何利用嵌套事务的 savepoint 特性呢, 我们用代码来说话
   

	ServiceA {
		
		/**
		 * 事务属性配置为 PROPAGATION_REQUIRED
		 */
		void methodA() {
			ServiceB.methodB();
		}
	
	}
	
	ServiceB {
		
		/**
		 * 事务属性配置为 PROPAGATION_REQUIRES_NEW
		 */	
		void methodB() {
		}
		
	}	

   

这种情况下, 因为 ServiceB#methodB 的事务属性为 PROPAGATION_REQUIRES_NEW, 所以两者不会发生任何关系, ServiceA#methodA 和 ServiceB#methodB 不会因为对方的执行情况而影响事务的结果, 因为它们根本就是两个事务, 在 ServiceB#methodB 执行时 ServiceA#methodA 的事务已经挂起了 (关于事务挂起的内容已经超出了本文的讨论范围, 有时间我会再写一些挂起的文章) .

那么 PROPAGATION_NESTED 又是怎么回事呢? 继续看代码

	ServiceA {
		
		/**
		 * 事务属性配置为 PROPAGATION_REQUIRED
		 */
		void methodA() {
			ServiceB.methodB();
		}
	
	}
	
	ServiceB {
		
		/**
		 * 事务属性配置为 PROPAGATION_NESTED
		 */	
		void methodB() {
		}
		
	}	

现在的情况就变得比较复杂了, ServiceB#methodB 的事务属性被配置为 PROPAGATION_NESTED, 此时两者之间又将如何协作呢? 从 Juergen Hoeller 的原话中我们可以找到答案, ServiceB#methodB 如果 rollback, 那么内部事务(即 ServiceB#methodB) 将回滚到它执行前的 SavePoint(注意, 这是本文中第一次提到它, 潜套事务中最核心的概念), 而外部事务(即 ServiceA#methodA) 可以有以下两种处理方式:

1. 改写 ServiceA 如下

	ServiceA {
		
		/**
		 * 事务属性配置为 PROPAGATION_REQUIRED
		 */
		void methodA() {
			try {
				ServiceB.methodB();
			} catch (SomeException) {
				// 执行其他业务, 如 ServiceC.methodC();
			}
		}
	
	}
	

这种方式也是潜套事务最有价值的地方, 它起到了分支执行的效果, 如果 ServiceB.methodB 失败, 那么执行 ServiceC.methodC(), 而 ServiceB.methodB 已经回滚到它执行之前的 SavePoint, 所以不会产生脏数据(相当于此方法从未执行过), 这种特性可以用在某些特殊的业务中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都没有办法做到这一点. (题外话 : 看到这种代码, 似乎似曾相识, 想起了 prototype.js 中的 Try 函数 )

2. 代码不做任何修改, 那么如果内部事务(即 ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滚到它执行之前的 SavePoint(在任何情况下都会如此),
   外部事务(即 ServiceA#methodA) 将根据具体的配置决定自己是 commit 还是 rollback (+MyCheckedException).
  
  
上面大致讲述了潜套事务的使用场景, 下面我们来看如何在 spring 中使用 PROPAGATION_NESTED, 首先来看 AbstractPlatformTransactionManager

	/**
	 * Create a TransactionStatus for an existing transaction.
	 */
	private TransactionStatus handleExistingTransaction(
			TransactionDefinition definition, Object transaction, boolean debugEnabled)
			throws TransactionException {

    ... 省略

		if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
			if (!isNestedTransactionAllowed()) {
				throw new NestedTransactionNotSupportedException(
						"Transaction manager does not allow nested transactions by default - " +
						"specify 'nestedTransactionAllowed' property with value 'true'");
			}
			if (debugEnabled) {
				logger.debug("Creating nested transaction with name [" + definition.getName() + "]");
			}
			if (useSavepointForNestedTransaction()) {
				// Create savepoint within existing Spring-managed transaction,
				// through the SavepointManager API implemented by TransactionStatus.
				// Usually uses JDBC 3.0 savepoints. Never activates Spring synchronization.
				DefaultTransactionStatus status =
						newTransactionStatus(definition, transaction, false, false, debugEnabled, null);
				status.createAndHoldSavepoint();
				return status;
			}
			else {
				// Nested transaction through nested begin and commit/rollback calls.
				// Usually only for JTA: Spring synchronization might get activated here
				// in case of a pre-existing JTA transaction.
				doBegin(transaction, definition);
				boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
				return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);
			}
		}
	}

  
一目了然

1. 我们要设置 transactionManager 的 nestedTransactionAllowed 属性为 true, 注意, 此属性默认为 false!!!

再看 AbstractTransactionStatus#createAndHoldSavepoint() 方法

	/**
	 * Create a savepoint and hold it for the transaction.
	 * @throws org.springframework.transaction.NestedTransactionNotSupportedException
	 * if the underlying transaction does not support savepoints
	 */
	public void createAndHoldSavepoint() throws TransactionException {
		setSavepoint(getSavepointManager().createSavepoint());
	}

  可以看到 Savepoint 是 SavepointManager.createSavepoint 实现的, 再看 SavepointManager 的层次结构, 发现
  其 Template 实现是 JdbcTransactionObjectSupport, 常用的 DatasourceTransactionManager, HibernateTransactionManager
  中的 TransactonObject 都是它的子类 :


  
  JdbcTransactionObjectSupport 告诉我们必须要满足两个条件才能 createSavepoint :
 
2. java.sql.Savepoint 必须存在, 即 jdk 版本要 1.4+
3. Connection.getMetaData().supportsSavepoints() 必须为 true, 即 jdbc drive 必须支持 JDBC 3.0

确保以上条件都满足后, 你就可以尝试使用 PROPAGATION_NESTED 了. (全文完)

评论

36 楼 realreal2000 2006-12-20  

非常好的分析，期待更多文章

35 楼 ahuaxuan 2006-12-14  

决定是精华的好贴，顶起来

34 楼 roc8633284 2006-12-14  

使用嵌套事务是有前提的，就是该嵌套事务可能需要做分支处理。否则用
PROPAGATION_REQUIRED 就足够了，如果子事务有异常，直接回滚。

33 楼 Feiing 2006-11-29  

lithium 写道

J2EE规范不要求应用服务器支持嵌套事务，也就是说，要使用嵌套事务，就不能用JtaTransactionManager，就不能支持分布式事务，对吗？

是的, PROPAGATION_NESTED 在 EJB 中不要求实现, 能不能使用要看 JTA 的具体实现

引用

Execute within a nested transaction if a current transaction exists, behave like PROPAGATION_REQUIRED else. There is no analogous feature in EJB.

Note: Actual creation of a nested transaction will only work on specific transaction managers. Out of the box, this only applies to the JDBC DataSourceTransactionManager when working on a JDBC 3.0 driver. Some JTA providers might support nested transactions as well.

32 楼 lithium 2006-11-29  

J2EE规范不要求应用服务器支持嵌套事务，也就是说，要使用嵌套事务，就不能用JtaTransactionManager，就不能支持分布式事务，对吗？

31 楼 jianfeng008cn 2006-11-29  

Feiing 写道

jianfeng008cn 写道

看了这篇文章后很多人说概念上清楚了，我怎么就觉得很迷糊呢！？仔细琢磨了一下，说一下我的想法和疑惑。
我觉得上面的这种想法其实是合理的，楼主把针对持久层的事务和程序的事务是不是较在一起了呢？（当然我也怀疑是自己犯本质上的错误了）
抛开数据库来理解，如果serviceA中的methodA中有调用ServiceB methodB,如果ServiceB的methodB调用出错需要rollback，那么理所当然，该方法所做的事情都应该取消，回到调用前，即rollback本来就该是这个样子的，哪来的脏数据呢？数据库的rollback是不会有数据库脏数据生成的吧
PROPAGATION_REQUIRES_NEW 的配置当然会有脏数据问题，因为正如他的英文意思，本身就是新的事务的意思呀。
这样说来Service 调用dao的说法也有其合理性，把业务逻辑和持久层很好的分离出来从而更好的剥离业务上的事务和持久层的事务。
我现在的理解是 事务只是保证一系列操作的原子属性，按照楼主的意思我想spring是不是不能处理多数据源情况下的事务处理呢。

经验很少，还望各位不啻指教，感谢了。

呵呵, 事务就是事务， 没有什么 "业务上的事务和持久层的事务" 的说法, 建议你先看一下 http://www.iteye.com/topic/11190

非常感谢，收获不小，继续努力！

30 楼 Feiing 2006-11-29  

jianfeng008cn 写道

看了这篇文章后很多人说概念上清楚了，我怎么就觉得很迷糊呢！？仔细琢磨了一下，说一下我的想法和疑惑。
我觉得上面的这种想法其实是合理的，楼主把针对持久层的事务和程序的事务是不是较在一起了呢？（当然我也怀疑是自己犯本质上的错误了）
抛开数据库来理解，如果serviceA中的methodA中有调用ServiceB methodB,如果ServiceB的methodB调用出错需要rollback，那么理所当然，该方法所做的事情都应该取消，回到调用前，即rollback本来就该是这个样子的，哪来的脏数据呢？数据库的rollback是不会有数据库脏数据生成的吧
PROPAGATION_REQUIRES_NEW 的配置当然会有脏数据问题，因为正如他的英文意思，本身就是新的事务的意思呀。
这样说来Service 调用dao的说法也有其合理性，把业务逻辑和持久层很好的分离出来从而更好的剥离业务上的事务和持久层的事务。
我现在的理解是 事务只是保证一系列操作的原子属性，按照楼主的意思我想spring是不是不能处理多数据源情况下的事务处理呢。

经验很少，还望各位不啻指教，感谢了。

呵呵, 事务就是事务， 没有什么 "业务上的事务和持久层的事务" 的说法, 建议你先看一下 http://www.iteye.com/topic/11190

29 楼 jianfeng008cn 2006-11-29  

引用

在我所见过的误解中, 最常见的是下面这种:


引用

假如有两个业务接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一个方法实现如下

/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
// 调用 ServiceB 的方法
ServiceB.methodB();
}

那么如果 ServiceB 的 methodB 如果配置了事务, 就必须配置为 PROPAGATION_NESTED



这种想法可能害了不少人, 认为 Service 之间应该避免互相调用, 其实根本不用担心这点，PROPAGATION_REQUIRED 已经说得很明白,
如果当前线程中已经存在事务, 方法调用会加入此事务, 果当前没有事务，就新建一个事务, 所以 ServiceB#methodB() 的事务只要遵循最普通的规则配置为 PROPAGATION_REQUIRED 即可, 如果 ServiceB#methodB (我们称之为内部事务, 为下文打下基础) 抛了异常, 那么 ServiceA#methodA(我们称之为外部事务) 如果没有特殊配置此异常时事务提交 (即 +MyCheckedException的用法), 那么整个事务是一定要 rollback 的, 什么 Service 只能调 Dao 之类的言论纯属无稽之谈, spring 只负责配置了事务属性方法的拦截, 它怎么知道你这个方法是在 Service 还是 Dao 里 ?

看了这篇文章后很多人说概念上清楚了，我怎么就觉得很迷糊呢！？仔细琢磨了一下，说一下我的想法和疑惑。
我觉得上面的这种想法其实是合理的，楼主把针对持久层的事务和程序的事务是不是较在一起了呢？（当然我也怀疑是自己犯本质上的错误了）
抛开数据库来理解，如果serviceA中的methodA中有调用ServiceB methodB,如果ServiceB的methodB调用出错需要rollback，那么理所当然，该方法所做的事情都应该取消，回到调用前，即rollback本来就该是这个样子的，哪来的脏数据呢？数据库的rollback是不会有数据库脏数据生成的吧
PROPAGATION_REQUIRES_NEW 的配置当然会有脏数据问题，因为正如他的英文意思，本身就是新的事务的意思呀。
这样说来Service 调用dao的说法也有其合理性，把业务逻辑和持久层很好的分离出来从而更好的剥离业务上的事务和持久层的事务。
我现在的理解是 事务只是保证一系列操作的原子属性，按照楼主的意思我想spring是不是不能处理多数据源情况下的事务处理呢。

经验很少，还望各位不啻指教，感谢了。

28 楼 naci007 2006-11-29  

好文呀

27 楼 fishermen 2006-11-28  

看了两遍，真是有收获，虽然暂时还没遇到需要嵌套事务的地方

26 楼 finalbone 2006-11-28  

大家请注意　Juergen Hoeller 的原文

引用

PROPAGATION_NESTED on the other hand starts a "nested" transaction, which is a true subtransaction of the existing one. What will happen is that a savepoint will be taken at the start of the nested transaction. íf the nested transaction fails, we will roll back to that savepoint. The nested transaction is part of of the outer transaction, so it will only be committed at the end of of the outer transaction.

Nested transactions essentially allow to try some execution subpaths as subtransactions: rolling back to the state at the beginning of the failed subpath, continuing with another subpath or with the main execution path there - all within one isolated transaction, and not losing any previous work done within the outer transaction.

For example, consider parsing a very large input file consisting of account transfer blocks: The entire file should essentially be parsed within one transaction, with one single commit at the end. But if a block fails, its transfers need to be rolled back, writing a failure marker somewhere. You could either start over the entire transaction every time a block fails, remembering which blocks to skip - or you mark each block as a nested transaction, only rolling back that specific set of operations, keeping the previous work of the outer transaction. The latter is of course much more efficient, in particular when a block at the end of the file fails.

Rolling back the entire transaction is the choice of the demarcation code/config that started the outer transaction.

So if an inner transaction throws an exception and is supposed to be rolled back (according to the rollback rules), the transaction will get rolled back to the savepoint taken at the start of the inner transaction. The immediate calling code can then decide to catch the exception and proceed down some other path within the outer transaction.

If the code that called the inner transaction lets the exception propagate up the call chain, the exception will eventually reach the demarcation code of the outer transaction. At that point, the rollback rules of the outer transaction decide whether to trigger a rollback. That would be a rollback of the entire outer transaction then.

So essentially, it depends on your exception handling. If you catch the exception thrown by the inner transaction, you can proceed down some other path within the outer transaction. If you let the exception propagate up the call chain, it's eventually gonna cause a rollback of the entire outer transaction.

PROPAGATION_NESTED 默认情况下只是回滚到子事务开始的地方（savepoint）　父事务不回滚

如果想使用PROPAGATION_NESTED　又想回滚父事务　该怎么办呢？

ServiceA {   
       
    /**  
     * 事务属性配置为 PROPAGATION_NESTED  
     */  
    void methodA() {   
        // do A ...

        ServiceB.methodB(); 
  
        // do A ...
    }   
  
}

OR

ServiceA {   
       
    /**  
     * 事务属性配置为 PROPAGATION_NESTED  
     */  
    void methodA() {   
        // do A ...
        try {   
            ServiceB.methodB();   
        } catch (Exception ex) {   
            throw ex;
        }   
        // do A ...
    }   
  
}

比如有两套系统　一套使用ibatis 一套使用hibernate

当两套系统进行集成整合的时候就会遇到事务嵌套的问题

比如想在 DataSourceTransactionManager 中调用hibernate操作　这时候麻烦就来了

有一种做法是将两套系统都交由 HibernateTransactionManager

因为 HibernateTransactionManager 是可以管理jdbc操作的

不知道将两套系统都交由 DataSourceTransactionManager 会怎么样？

或者两个事务管理器并存　用PROPAGATION_NESTED？ 回头试一试．．．

25 楼 Tin 2006-11-28  

savepoint支持是JDBC 3.0规定必须支持的特性么？不知道我们常用的数据库哪个版本配合哪个驱动支持？
还有，看AbstractPlatformTransactionManager代码，嵌套事务还可以通过JTA的嵌套事务支持，这种用法哪个应用程序服务器支持呢？
看完这篇文章概念上感觉明白了，就是不知道背后支持怎么样:D
手里项目还没有遇到过需要嵌套事务的情况，有机会尝试一下。

24 楼 HH 2006-11-28  

大家都不明白嵌套事务，可见这个东西很少用。

做到现在还没有碰到过需要使用嵌套事务的地方。

23 楼 finalbone 2006-11-28  

个人理解只有需要根据子事务的执行情况进行分支处理的情况下才是nested的用武之地
savepoint是嵌套事务回滚的实现方式 需要注意的是使用它的限制条件

而required_new就更少用到了 一般情况下可以将此部分代码放在事务之外执行 实在剥离不开才会用到

22 楼 Feiing 2006-11-27  

together 写道

Feiing 写道

当然, 就算所有嵌套事务都已经成功, 外部事务还是可能因为嵌套事务的执行结果而导致失败,  此时整个事务都要 roll back ，这也是嵌套事务的重要特性之一, 即外部事务和嵌套事务互相影响

反过来说，所有嵌套事务都执行成功，外部事务也执行成功。那么发部事务要发送commit请求给各个嵌套事务，以同时提交，是这个意思吗？

按照定义是这样的

together 写道

那么对于数据库来说，它相当于在瞬间处理多个事务的commit，在中间的任何一步也是有可能出错的。那这个时候整个事务的回滚如何进行呢？

因为嵌套事务都有自己的 savepoint, 所以整个事务都可以回滚, 至于 savepoint 的具体实现, 那就是数据库厂商的事了.

但是嵌套事务可能会引起效率问题, 如果没有特殊的需求, PROPAGATION_REQUIRED 已经足够了

21 楼 zhh1981 2006-11-27  

分析的很好，现在市面上的书对此都不是讲的很透彻！

20 楼 andyao 2006-11-27  

很好的分析。
终于弄清楚nested和required_new的区别了

19 楼 davidzhao 2006-11-27  

嗯 写的很棒 原来这方面的东西我只是在Oracle的资料上看到的
在使用spring的时候没有注意到
没想到楼主解释的这么详尽

18 楼 together 2006-11-27  

Feiing 写道

当然, 就算所有嵌套事务都已经成功, 外部事务还是可能因为嵌套事务的执行结果而导致失败,  此时整个事务都要 roll back ，这也是嵌套事务的重要特性之一, 即外部事务和嵌套事务互相影响

反过来说，所有嵌套事务都执行成功，外部事务也执行成功。那么发部事务要发送commit请求给各个嵌套事务，以同时提交，是这个意思吗？
那么对于数据库来说，它相当于在瞬间处理多个事务的commit，在中间的任何一步也是有可能出错的。那这个时候整个事务的回滚如何进行呢？

17 楼 boogie 2006-11-26  

绝对OK的文章！