Spring声明式事务管理源码解读之事务提交

/**
*作者：张荣华(ahuaxuan)
*2007-06-11
*转载请注明出处及作者
*/

简介：上次说到spring声明式事务管理的事务开始部分，按流程来讲，下面应该提交事务了， spring的声明式事务管理其实是比较复杂的，事实上这种复杂性正是由于事务本身的复杂性导致的，如果能用两三句话就把这部分内容说清楚是不现实的，也是不成熟的，而我对这部分的理解也可能是不全面的，还是那句话，希望大家和我一起把本贴的质量提交起来。
在下面的文章中，我讲会多次提到第一篇文章，第一篇文章的地址是：http://www.iteye.com/topic/87426
如果要理解事务提交的话，理解事务开始是一个前提条件,所以请先看第一篇文章，再来看这篇
如果你仔细看下去，我想肯定是有很多收获，因为我们确实能从spring的代码和思想中学到很多东西。

正文：

其实俺的感觉就是事务提交要比事务开始复杂，看事务是否提交我们还是要回到TransactionInterceptor类的invoke方法

public Object invoke(MethodInvocation invocation) throws Throwable {
		// Work out the target class: may be <code>null</code>.
		// The TransactionAttributeSource should be passed the target class
		// as well as the method, which may be from an interface
		Class targetClass = (invocation.getThis() != null) ? invocation.getThis().getClass() : null;
		
		// Create transaction if necessary.
		TransactionInfo txInfo = createTransactionIfNecessary(invocation.getMethod(), targetClass);

		Object retVal = null;
		try {
			// This is an around advice.
			// Invoke the next interceptor in the chain.
			// This will normally result in a target object being invoked.
			retVal = invocation.proceed();
		}
		catch (Throwable ex) {
			// target invocation exception
			doCloseTransactionAfterThrowing(txInfo, ex);
			throw ex;
		}
		finally {
			doFinally(txInfo);//业务方法出栈后必须先执行的一个方法
		}
		doCommitTransactionAfterReturning(txInfo);
		return retVal;
	}

其中的doFinally(txInfo)那一行很重要，也就是说不管如何，这个doFinally方法都是要被调用的，为什么它这么重要呢，举个例子:
我们还是以propregation_required来举例子吧，假设情况是这样的，AService中有一个方法调用了BService中的，这两个方法都处在事务体之中，他们的传播途径都是required。那么调用开始了，AService的方法首先入方法栈，并创建了TransactionInfo的实例，接着BService的方法入栈，又创建了一个TransactionInfo的实例，而重点要说明的是TransactionInfo是一个自身关联的内部类，第二个方法入栈时，会给新创建的TransactionInfo的实例设置一个属性，就是TransactionInfo对象中的private TransactionInfo oldTransactionInfo;属性，这个属性表明BService方法的创建的TransactionInfo对象是有一个old的transactionInfo对象的，这个oldTransactionInfo对象就是AService方法入栈时创建的TransactionInfo对象，我们还记得在createTransactionIfNecessary方法里有这样一个方法吧：

protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
				// We always bind the TransactionInfo to the thread, even if we didn't create
		// a new transaction here. This guarantees that the TransactionInfo stack
		// will be managed correctly even if no transaction was created by this aspect.
		txInfo.bindToThread();
		return txInfo;
	}

就是这个bindToThread()方法在作怪：
private void bindToThread() {
			// Expose current TransactionStatus, preserving any existing transactionStatus for
			// restoration after this transaction is complete.
			oldTransactionInfo = (TransactionInfo) currentTransactionInfo.get();
			currentTransactionInfo.set(this);
		}

如果当前线程中已经有了一个TransactionInfo，则拿出来放到新建的transactionInfo对象的oldTransactionInfo属性中，然后再把新建的TransactionInfo设置到当前线程中。

这里有一个概念要搞清楚，就是TransactionInfo对象并不是表明事务状态的对象，表明事务状态的对象是TransactionStatus对象，这个对象同样是TransactionInfo的一个属性（这一点，我在前面一篇文章中并没有讲清楚）。

接下来BService中的那个方法返回，那么该它退栈了，它退栈后要做的就是doFinally方法，即把它的oldTransactionInfo设置到当前线程中（这个TransactionInfo对象显然就是AService方法入栈时创建的，怎么现在又要设置到线程中去呢，原因就是BService的方法出栈时并不提交事务，因为BService的传播途径是required，所以要把栈顶的方法所创建transactioninfo给设置到当前线程中），即调用AService的方法时所创建的TransactionInfo对象。那么在AServie的方法出栈时同样会设置TransactionInfo对象的oldTransactionInfo到当前线程，这时候显然oldTransactionInfo是空的，但AService中的方法会提交事务，所以它的oldTransactionInfo也应该是空了。

在这个小插曲之后，么接下来就应该是到提交事务了，之前在AService的方法出栈时，我们拿到了它入栈时创建的TransactionInfo对象，这个对象中包含了AService的方法事务状态。即TransactionStatus对象，很显然，太显然了，事务提交中的任何属性都和事务开始时的创建的对象息息相关，这个TransactionStatus对象哪里来的，我们再回头看看createTransactionIfNessary方法吧：

protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
			txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));
		}

再看看transactionManager.getTransaction(txAttr)方法吧：

public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {
		
		else if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||
				definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||
		    definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
			if (debugEnabled) {
				logger.debug("Creating new transaction with name [" + definition.getName() + "]");
			}
			doBegin(transaction, definition);
			boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
			return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);//注意这里的返回值，返回的就是一个TransactionStatus对象,这个对象表明了一个事务的状态，比如说是否是一个新的事务，事务是否已经结束，等等，这个对象是非常重要的，在事务提交的时候还是会用到它的。		}
			}
	}

还有一点需要说明的是，AService的方法在执行之前创建的transactionstatus确实是通过这个方法创建的，但是，BService的方法在执行之前创建transactionstatus的方法就与这个不一样了，下面会有详解。

回顾了事务开始时所调用的方法之后，是不是觉得现在对spring如何处理事务越来越清晰了呢。由于这么几个方法的调用，每个方法入栈之前它的事务状态就已经被设置好了。这个事务状态就是为了在方法出栈时被调用而准备的。

让我们再次回到BService中的方法出栈的那个时间段，看看spring都做了些什么，我们知道，后入栈的肯定是先出栈，BService中的方法后入栈，拿它肯定要先出栈了，它出栈的时候是要判断是否要提交事务，释放资源的，让我们来看看TransactionInterceptor的invoke的最后那个方法doCommitTransactionAfterReturning：

protected void doCommitTransactionAfterReturning(TransactionInfo txInfo) {
		if (txInfo != null && txInfo.hasTransaction()) {
			if (logger.isDebugEnabled()) {
				logger.debug("Invoking commit for transaction on " + txInfo.joinpointIdentification());
			}
			this.transactionManager.commit(txInfo.getTransactionStatus());
//瞧：提交事务时用到了表明事务状态的那个TransactionStatus对象了。
		}
	}

看这个方法的名字就知道spring是要在业务方法出栈时提交事务，貌似很简单，但是事实是这样的吗？ 我们接着往下看。

public final void commit(TransactionStatus status) throws TransactionException {
		DefaultTransactionStatus defStatus = (DefaultTransactionStatus) status;

		if (defStatus.isCompleted()) {
			throw new IllegalTransactionStateException(
					"Transaction is already completed - do not call commit or rollback more than once per transaction");
		}
		if (defStatus.isLocalRollbackOnly()) {
			if (defStatus.isDebug()) {
				logger.debug("Transactional code has requested rollback");
			}
			processRollback(defStatus);
			return;
		}
		if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {
			if (defStatus.isDebug()) {
				logger.debug("Global transaction is marked as rollback-only but transactional code requested commit");
			}
			processRollback(defStatus);
			throw new UnexpectedRollbackException(
					"Transaction has been rolled back because it has been marked as rollback-only");
		}

		processCommit(defStatus);
	}

上面这段代码就是transactionmanager中的commit，但是看上去，它又把自己的职责分配给别人了，从代码里我们看到，如果事务已经结束了就抛异常，如果事务是rollbackonly的，那么就rollback吧，但是按照正常流程，我们还是想来看一下，事务的提交，就是processCommit(status)这个方法吧。

private void processCommit(DefaultTransactionStatus status) throws TransactionException {
		try {
			boolean beforeCompletionInvoked = false;
			try {
				triggerBeforeCommit(status);
				triggerBeforeCompletion(status);
				beforeCompletionInvoked = true;
				if (status.hasSavepoint()) {
					if (status.isDebug()) {
						logger.debug("Releasing transaction savepoint");
					}
					status.releaseHeldSavepoint();
				}
				else if (status.isNewTransaction()) {//这个判断非常重要，下面会详细讲解这个判断的作用
					if (status.isDebug()) {
						logger.debug("Initiating transaction commit");
					}
					boolean globalRollbackOnly = status.isGlobalRollbackOnly();
					doCommit(status);
					// Throw UnexpectedRollbackException if we have a global rollback-only
					// marker but still didn't get a corresponding exception from commit.
					`````````````````````
	}

我们注意到，在判断一个事务是否是新事务之前还有一个status.hasSavepoint()的判断，我认为这个判断事实上就是嵌套事务的判断，即判断这个事务是否是嵌套事务，如果不是嵌套事务，则再判断它是否是一个新事务，下面这段话就非常重要了，BService的中的方法是先出栈的，也就是说在调用BService之前的创建的那个事务状态对象在这里要先被判断，但是由于在调用BService的方法之前已经创建了一个Transaction和Session（假设我们使用的是hibernate3），这时候在创建第二个TransactionInfo（再强调一下吧，TransactionInfo并不是Transaction，Transaction是真正的事务对象，TransactionInfo只不过是一个辅助类而已，用来记录一系列状态的辅助类）的TransactionStatus的时候就会进入下面这个方法（当然在这之前会判断一下当前线程中是否已经有了一个SessionHolder对象，不清楚SessionHolder作用的同学情况第一篇文章），这个方法其实应该放到第一篇文章中讲的，但是想到如果不讲事务提交就讲这个方法好像没有这么贴切，废话少说，我们来看一下吧：

private TransactionStatus handleExistingTransaction(
			TransactionDefinition definition, Object transaction, boolean debugEnabled)
			throws TransactionException {

		if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NEVER) {
			throw new IllegalTransactionStateException(
					"Transaction propagation 'never' but existing transaction found");
		}

		if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NOT_SUPPORTED) {
			if (debugEnabled) {
				logger.debug("Suspending current transaction");
			}
			Object suspendedResources = suspend(transaction);
			boolean newSynchronization = (this.transactionSynchronization == SYNCHRONIZATION_ALWAYS);
			return newTransactionStatus(
					definition, null, false, newSynchronization, debugEnabled, suspendedResources);
		}

		if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW) {
			if (debugEnabled) {
				logger.debug("Suspending current transaction, creating new transaction with name [" +
						definition.getName() + "]");
			}
			Object suspendedResources = suspend(transaction);
			doBegin(transaction, definition);
			boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
			return newTransactionStatus(
					definition, transaction, true, newSynchronization, debugEnabled, suspendedResources);
		}

		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);
			}
		}

		// Assumably PROPAGATION_SUPPORTS.
		if (debugEnabled) {
			logger.debug("Participating in existing transaction");
		}
		boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
		return newTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null);
	}

我们看到这个方法其实很明了，就是什么样的传播途径就创建什么样的transactionstatus，这个方法是在事务开始时被调用的，拿到我们之前举的例子中来看下，我们就恍然大悟了，原来，如果之前已经创建过事务，那个这个新建的transactionstauts就不应该是属于一个newTransaction了，所以第3个参数就是false了。

也就是说，在BService的方法出栈要要执行processcommit，但是由于BService的那个TransactionStatus不是一个newTransaction，所以它根本不会触发这个动作：

else if (status.isNewTransaction()) {//这个判断非常重要，下面会详细讲解这个判断的作用
					if (status.isDebug()) {
						logger.debug("Initiating transaction commit");
					}
boolean globalRollbackOnly = status.isGlobalRollbackOnly();
					doCommit(status);
}

也就是说在BService的方法出栈后，事务是不会提交的。这完全符合propragation_required的模型。
而在AService的方法出栈后，AService的方法所对应的那个TransactionStatus对象的newTransaction属性是为true的，即它会触发上面这段代码，进行真正的事务提交。让我们回想一下AService方法入栈之前创建TransactionStatus对象的情形吧：
newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);看到第3个参数为true没有。

那么事务该提交了吧，事务的提交我想使用过hibernate的人都知道怎么提交了：
txObject.getSessionHolder().getTransaction().commit();
从当前线程中拿到SessionHolder，再拿到开始事务的那个Transaction对象，然后再commit事务。在没有用spring之前，我们经常这么做。呵呵。

好吧，我已经说到了spring声明式事务管理的70%到80%的内容了，这70%到80%的内容看上去还是非常容易理解的，如果把这两篇文章认真看过，我相信会有所收获的，剩下的内容需要靠大家自己去挖掘了，因为另剩下的内容可是需要花费很多时间的，因为牵扯的东西实在是太多了，呵呵。最后祝大家阅读愉快，因为我的文笔实在是让大家的眼睛受罪了。

作者：张荣华，未经作者同意不得随意转载！

评论

8 楼 ahuaxuan 2007-08-22  

其实我到觉得spring只所以这样做就是为了那些“某些”情况的，因为如果在那种情况下，要得到这个transactioninfo就比较方便了，否则就麻烦了，这个hibernate中也有类似的做法，就是为了扩展方便之类的，比如说在它的
EventListeners类中有这样的写法：

private DirtyCheckEventListener[] dirtyCheckEventListeners = { new DefaultDirtyCheckEventListener() };
	private FlushEventListener[] flushEventListeners = { new DefaultFlushEventListener() };
	private EvictEventListener[] evictEventListeners = { new DefaultEvictEventListener() };
	private LockEventListener[] lockEventListeners = { new DefaultLockEventListener() };

我觉得它这样做就是为了扩展起来方便，否则只有一个元素实在没有必要用数组了

7 楼 jiwenke 2007-08-17  

ahuaxuan 写道

我看到spring确实有调用它的地方：

/**
	 * Subclasses can use this to return the current TransactionInfo.
	 * Only subclasses that cannot handle all operations in one method,
	 * such as an AspectJ aspect involving distinct before and after advice,
	 * need to use this mechanism to get at the current TransactionInfo.
	 * An around advice such as an AOP Alliance MethodInterceptor can hold a
	 * reference to the TransactionInfo throughout the aspect method.
	 * <p>A TransactionInfo will be returned even if no transaction was created.
	 * The <code>TransactionInfo.hasTransaction()</code> method can be used to query this.
	 * <p>To find out about specific transaction characteristics, consider using
	 * TransactionSynchronizationManager's <code>isSynchronizationActive()</code>
	 * and/or <code>isActualTransactionActive()</code> methods.
	 * @return TransactionInfo bound to this thread, or <code>null</code> if none
	 * @see TransactionInfo#hasTransaction()
	 * @see org.springframework.transaction.support.TransactionSynchronizationManager#isSynchronizationActive()
	 * @see org.springframework.transaction.support.TransactionSynchronizationManager#isActualTransactionActive()
	 */
	protected static TransactionInfo currentTransactionInfo() throws NoTransactionException {
		return (TransactionInfo) transactionInfoHolder.get();
	}

这个是spring2.0的代码，只有在某些情况下才会使用，看注释吧

这里说只是在某些情况会使用。但是

引用

接下来BService中的那个方法返回，那么该它退栈了，它退栈后要做的就是doFinally方法，即把它的oldTransactionInfo设置到当前线程中（这个TransactionInfo对象显然就是AService方法入栈时创建的，怎么现在又要设置到线程中去呢，原因就是 BService的方法出栈时并不提交事务，因为BService的传播途径是required，所以要把栈顶的方法所创建 transactioninfo给设置到当前线程中），即调用AService的方法时所创建的TransactionInfo对象。那么在 AServie的方法出栈时同样会设置TransactionInfo对象的oldTransactionInfo到当前线程，这时候显然 oldTransactionInfo是空的，但AService中的方法会提交事务，所以它的oldTransactionInfo也应该是空了。

这一系列操作却总是要做的，这又是为什么呢？只存不取？或者具体什么时候去取？

6 楼 ahuaxuan 2007-08-17  

jiwenke 写道

ahuaxuan 写道

这个TransactionInfo是一个状态对象，代表每个事务（或者假事务，既在事务体内，但是自己又没有创建事务）的事务属性，它在方法调用前被创建（在声明式事务里是根据配置），在业务方法结束后需要用到它来判断事务是否有事务，有事务那是否提交等等一系列的判断。

引用

然后就直接提交了，没有看到去currentTransactionInfo中去取哪？

没太明白你的意思，当前的TransactionInfo就是在这个invoke方法里啊

不好意思，没有写清楚，我的意思是这样的：
在TransactionInterceptor中开始事务的时候，使用了TransactionInfo的bindToThread来绑定线程和A/B service的oldTransactionInfo,但是没有地方看到这里的oldTransactionInfo起作用：
因为在为A/B方法准备好TransactionInfo以后的代码是

finally {
 cleanupTransactionInfo(txInfo);
}
 commitTransactionAfterReturning(txInfo);

而cleanupTransactionInfo就把TransactionInfo给restore了：

		private void restoreThreadLocalStatus() {
			// Use stack to restore old transaction TransactionInfo.
			// Will be <code>null</code> if none was set.
			currentTransactionInfo.set(this.oldTransactionInfo);
		}

这个currentTransactionInfo是一个ThreadLocal变量,也就是说和当前线程绑定的TransactionInfo会是当前的oldTransactionInfo,比如B退栈的时候是A的TransactionInfo,A的是NULL,但是和后面就直接提交了，一直也没看到使用这个和线程绑定的oldTransactionInfo被使用 - 那为什么要做这样一系列的设置？

我看到spring确实有调用它的地方：

/**
	 * Subclasses can use this to return the current TransactionInfo.
	 * Only subclasses that cannot handle all operations in one method,
	 * such as an AspectJ aspect involving distinct before and after advice,
	 * need to use this mechanism to get at the current TransactionInfo.
	 * An around advice such as an AOP Alliance MethodInterceptor can hold a
	 * reference to the TransactionInfo throughout the aspect method.
	 * <p>A TransactionInfo will be returned even if no transaction was created.
	 * The <code>TransactionInfo.hasTransaction()</code> method can be used to query this.
	 * <p>To find out about specific transaction characteristics, consider using
	 * TransactionSynchronizationManager's <code>isSynchronizationActive()</code>
	 * and/or <code>isActualTransactionActive()</code> methods.
	 * @return TransactionInfo bound to this thread, or <code>null</code> if none
	 * @see TransactionInfo#hasTransaction()
	 * @see org.springframework.transaction.support.TransactionSynchronizationManager#isSynchronizationActive()
	 * @see org.springframework.transaction.support.TransactionSynchronizationManager#isActualTransactionActive()
	 */
	protected static TransactionInfo currentTransactionInfo() throws NoTransactionException {
		return (TransactionInfo) transactionInfoHolder.get();
	}

这个是spring2.0的代码，只有在某些情况下才会使用，看注释吧

5 楼 jiwenke 2007-08-16  

假设：
A里面包含了B service,那么对这些事务处理的执行过程是这样的：
PrepA - Prep B - Cleanup B - Commit B - Cleanup A - Commit A,这样的话，在Prep A中设的TransactionInfo的old是null,currentTransactionInfo中的是TransactionInfo(a)
然后到Prep B，它的TransactionInfo(b)的old是从currentTransactionInfo中取的，就是TransactionInfo(a),然后cleanup B 把currentTransactionInfo中的设为TransactionInfo(a),然后Commit B中用的是还是TransactionInfo(B)啊 ！ 到了cleanup a的时候，把currentTransactionInfo设为null,然后就commit a, 用的是TransactionInfo(a) - 从这个过程上看，没有看到使用那个线程里的TrsanctionInfo啊？是不是因该commitB 的时候会用到这个old的，也就是transactionInfo(a),但是没有看到使用啊？

4 楼 jiwenke 2007-08-16  

ahuaxuan 写道

这个TransactionInfo是一个状态对象，代表每个事务（或者假事务，既在事务体内，但是自己又没有创建事务）的事务属性，它在方法调用前被创建（在声明式事务里是根据配置），在业务方法结束后需要用到它来判断事务是否有事务，有事务那是否提交等等一系列的判断。

引用

然后就直接提交了，没有看到去currentTransactionInfo中去取哪？

没太明白你的意思，当前的TransactionInfo就是在这个invoke方法里啊

不好意思，没有写清楚，我的意思是这样的：
在TransactionInterceptor中开始事务的时候，使用了TransactionInfo的bindToThread来绑定线程和A/B service的oldTransactionInfo,但是没有地方看到这里的oldTransactionInfo起作用：
因为在为A/B方法准备好TransactionInfo以后的代码是

finally {
 cleanupTransactionInfo(txInfo);
}
 commitTransactionAfterReturning(txInfo);

而cleanupTransactionInfo就把TransactionInfo给restore了：

		private void restoreThreadLocalStatus() {
			// Use stack to restore old transaction TransactionInfo.
			// Will be <code>null</code> if none was set.
			currentTransactionInfo.set(this.oldTransactionInfo);
		}

这个currentTransactionInfo是一个ThreadLocal变量,也就是说和当前线程绑定的TransactionInfo会是当前的oldTransactionInfo,比如B退栈的时候是A的TransactionInfo,A的是NULL,但是和后面就直接提交了，一直也没看到使用这个和线程绑定的oldTransactionInfo被使用 - 那为什么要做这样一系列的设置？

3 楼 ahuaxuan 2007-08-16  

这个TransactionInfo是一个状态对象，代表每个事务（或者假事务，既在事务体内，但是自己又没有创建事务）的事务属性，它在方法调用前被创建（在声明式事务里是根据配置），在业务方法结束后需要用到它来判断事务是否有事务，有事务那是否提交等等一系列的判断。

引用

然后就直接提交了，没有看到去currentTransactionInfo中去取哪？

没太明白你的意思，当前的TransactionInfo就是在这个invoke方法里啊

2 楼 jiwenke 2007-08-15  

ahuaxuan 写道

就是这个bindToThread()方法在作怪：
private void bindToThread() {
// Expose current TransactionStatus, preserving any existing transactionStatus for
// restoration after this transaction is complete.
oldTransactionInfo = (TransactionInfo) currentTransactionInfo.get();
currentTransactionInfo.set(this);
}
如果当前线程中已经有了一个TransactionInfo，则拿出来放到新建的transactionInfo对象的oldTransactionInfo属性中，然后再把新建的TransactionInfo设置到当前线程中。

这里有一个概念要搞清楚，就是TransactionInfo对象并不是表明事务状态的对象，表明事务状态的对象是TransactionStatus对象，这个对象同样是TransactionInfo的一个属性（这一点，我在前面一篇文章中并没有讲清楚）。

接下来BService中的那个方法返回，那么该它退栈了，它退栈后要做的就是doFinally方法，即把它的oldTransactionInfo设置到当前线程中（这个TransactionInfo对象显然就是AService方法入栈时创建的，怎么现在又要设置到线程中去呢，原因就是BService的方法出栈时并不提交事务，因为BService的传播途径是required，所以要把栈顶的方法所创建transactioninfo给设置到当前线程中），即调用AService的方法时所创建的TransactionInfo对象。那么在AServie的方法出栈时同样会设置TransactionInfo对象的oldTransactionInfo到当前线程，这时候显然oldTransactionInfo是空的，但AService中的方法会提交事务，所以它的oldTransactionInfo也应该是空了。

我这里有个问题想请教一下：
在什么时候看到这个绑定到线程的TransactionInfo被使用？
在在码中有个

finally {
  cleanupTransactionInfo(txInfo);
			}
  commitTransactionAfterReturning(txInfo);

然后就直接提交了，没有看到去currentTransactionInfo中去取哪？而在cleanup中也只是看到把ThreadLocal中设成old的那个，也就是会设成A service设的那个。

1 楼 ahuaxuan 2007-06-12  

回头再看这篇文章，觉得写得可能太抽象了，因为没有对transaction有一个大体的概念的话，可能真的不太容易理解，当然本来就清楚的人除外，所以我上网找了一下spring1.2.x的关于transaction部分的uml图

http://opensource.objectsbydesign.com/spring/
上面这个url是spring的1.2.x的uml图的网址。

对着这个uml图再来看文章，我想会有些帮助