解惑 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 中一共定义了六种事务传播属性, 如果你觉得看起来不够直观, 那么我来转贴一个满大街都有的翻译



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



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

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





    也就是说, 最容易弄混淆的其实是 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 了. (全文完)

很棒的分析，让我也搞清楚了 PROPAGATION_NESTED ，而以前一直不清楚。

这里还是不明白,为什么PROPAGATION_REQUIRES_NEW不能做到呢?
如果ServiceB.methodB设成PROPAGATION_REQUIRES_NEW,当他执行失败时,ServiceA.methodA也有机会选择如何处理呀?

是的, 但是关键在于选择 PROPAGATION_REQUIRES_NEW 时 ServiceB.methodB 没办法回滚到它执行之前的 SavePoint, 这时已经产生了一些脏数据, 而这些脏数据将可能导致后面的程序执行出错, 所以 SavePoint 是潜套事务的核心概念, 也是使用嵌套事务的必要前提

我的认识是PROPAGATION_NESTED 和PROPAGATION_REQUIRES_NEW 的主要区别在于，如果 ServiceB.methodB 完成执行并“提交”后，如果后面的ServiceA.methodA部分失败，那么如果设置成PROPAGATION_NESTED 那么ServiceB.methodB将需要回滚；如果设置成PROPAGATION_REQUIRES_NEW 那么ServiceB.methodB将不受影响而持久化事务内容。

不知道我的认识对不对，如果不是这样的，而NESTED属性只是体现在“它起到了分支执行的效果”，那么我的疑问就和daquan198163一样了

不好意思，发帖时没看到Feiing的回帖，你的意思是说ServiceA.methodA，和ServiceB.methodB中同时存在对相同事务资源的操作，从而产生这个SavePoint的关键概念，是吗？

呵呵, 可能原来关于PROPAGATION_NESTED 和PROPAGATION_REQUIRES_NEW 的区别描述不够清楚，我在原文中增加了一些解释，用红色标志出来了 

也不一定是同时存在对相同事务资源的操作， 嵌套事务本身可能是对其他资源的操作， 但是这个操作在业务上影响外部事务的执行。潜套事务本身就是外部事务的一个子事务, SavePoint 就是一份快照, 它使得自身出错时可以回滚到出错前的状态

我这里再转一篇嵌套事务的文章供大家参考, 文章来自于
http://book.csdn.net/bookfiles/121/1001213920.shtml



显式事务可以嵌套，即在显式事务中开始另一个显式事务是可能的。支持嵌套事务的最重要原因是为了允许在存储过程中使用事务而不必顾及这个事务本身是否是在另一个事务中被调用的。但是SQL Server是如何处理嵌套事务的？我们可以通过两个简单的示例来探究一下嵌套事务。

Ø       探究嵌套事务

1.    启动SQL Server Management Studio并打开一个“新建查询”窗口。

2.    通过@@TRANCOUNT来发现SQL Server是如何处理嵌套事务的。键入并执行以下批(此例的代码包含在示例文件NestingTransactions.sql中)：

PRINT 'Trancount before transaction: ' + CAST(@@trancount as char(1))

BEGIN TRAN

    PRINT 'After first BEGIN TRAN: ' + CAST(@@trancount as char(1))

    BEGIN TRAN

        PRINT 'After second BEGIN TRAN: ' + CAST(@@trancount as char(1))

    COMMIT TRAN

    PRINT 'After first COMMIT TRAN: ' + CAST(@@trancount as char(1))

COMMIT TRAN

PRINT 'After second COMMIT TRAN: ' + CAST(@@trancount as char(1))

3.    在结果中，可以看到每一个BEGIN TRAN 语句都会使@@TRANCOUNT增加1并且每一个COMMIT TRAN语句都会使其减少1。如前所述，一个值为0的@@TRANCOUNT意味着没有打开的事务。因此，在@@TRANCOUNT值从1降到0时结束的事务发生在外层事务提交的时候。因此，每一个内部事务都需要提交。由于事务起始于第一个BEGIN TRAN并结束于最后一个COMMIT TRAN，因此最外层的事务决定了是否完全提交内部的事务。如果最外层的事务没有被提交，其中嵌套的事务也不会被提交。

4.    键入并执行以下批来检验事务回滚时所发生的情况：

USE AdventureWorks

BEGIN TRAN

    PRINT 'After 1st BEGIN TRAN: ' + CAST(@@trancount as char(1))

    BEGIN TRAN

        PRINT 'After 2nd BEGIN TRAN: ' + CAST(@@trancount as char(1))

            BEGIN TRAN

            PRINT 'After 3rd BEGIN TRAN: ' + CAST(@@trancount as char(1))

 

            UPDATE Person.Contact

            SET EmailAddress = 'test@test.at'

            WHERE ContactID = 20

 

            COMMIT TRAN

        PRINT 'After first COMMIT TRAN: ' + CAST(@@trancount as char(1))

ROLLBACK TRAN

PRINT 'After ROLLBACK TRAN: ' + CAST(@@trancount as char(1))

 

SELECT EmailAddress FROM Person.Contact

WHERE ContactID = 20;

5.    在这个示例中，联系人的电子邮件地址在一个嵌套事务中被更新，这会被立即提交。然后ROLLBACK TRAN被执行。ROLLBACK TRAN将@@TRANCOUNT减为0并回滚整个事务及其中嵌套的事务，无论它们是否已经被提交。因此，嵌套事务中所做的更新被回滚，数据没有任何改变。

始终牢记，在嵌套的事务中，只有最外层的事务决定着是否提交内部事务。每一个COMMIT TRAN语句总是应用于最后一个执行的BEGIN TRAN。因此，对于每一个BEGIN TRAN，必须调用一个COMMIT TRAN来提交事务。ROLLBACK TRAN语句总是属于最外层的事务，并且因此总是回滚整个事务而不论其中打开了多少嵌套事务。正因为此，管理嵌套事务很复杂。正如本节最初提到的那样，如果每一个嵌套存储过程都在自身中开始一个事务，那么嵌套事务大部分会发生在嵌套存储过程中。要避免嵌套事务，可以在过程开始处检查@@TRANCOUNT的值，以此来确定是否需要开始一个事务。如果@@TRANCOUNT大于0，因为过程已经处于一个事务中并且调用实例可以在错误发生时回滚事务。

1.parent.begin();
  update(1);
  child = parent.createChild();
  child.begin();
  update(2);
  child.rollback() (or commit but fail);
  update(3);
  parent.commit();//假设成功，则结果为1,3被修改,2不被修改


3.parent.begin();
  update(1);
  child = parent.createChild();
  child.begin();
  update(2);
  child.commit(); //假设成功
  update(3);
  parent.rollback() (or commit but fail);//结果为1,2,3都不被修改
 

3.parent.begin();
  update(1);
  child = parent.createChild();
  child.begin();
  update(2)
  child.commit(); //假设成功
  update(3)
  //下面这句，是否会出现这样的情况所导致的提交失败:
        虽然子事务在上面提交成功了，但是还会有在子事务中操作的资源所引致的提交失败？
     结果为1,2,3都不被修改?
  parent.commit();