spring声明式事务

引用

http://www.iteye.com/topic/87426

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

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

简介：事务是所有企业应用系统的核心，之前人们使用ejb的时候，容器事务管理(CMT)，是slsb最令人称道的地方，据说很多人使用ejb，使用slsb就是为了cmt，但是spring出现之后，格局就变了，因为程序员又多了一种选择，就是声明式事务管理，声明式事务管理是基于AOP的，及AOP是它的底层特性，本文的目的就是为了和大家探讨一下spring的声明式事务管理，从源代码来分析它的背后的思想。（谢谢异常的建议，因为本文原来没有简介）


这个是我昨天在解决问题是看源码得一点体验，可能说得比较大概，希望大家多多讨论，把本贴得质量提高上去，因为spring实现的事务管理这部分我相信还是有点复杂的。一个人未必能想得十分清楚
在spring的声明式事务管理中，它是如何判定一个及标记一个方法是否应该是处在事务体之中呢。

首先要理解的是spring是如何来标记一个方法是否应该处在事务体之中的。有这样一个接口TransactionDefinition，其中定义了很多常量，它还有一个子接口TransactionAttribute，其中只有一个方法rollback。
TransactionDefinition中有很多常量定义，它们分别属于两种类型，传播途径和隔离级别
Java代码  收藏代码

    /**
         * 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; 

当然其中也定义了隔离级别
/**
Java代码  收藏代码

    * A constant indicating that dirty reads are prevented; non-repeatable reads 
     * and phantom reads can occur. This level only prohibits a transaction 
     * from reading a row with uncommitted changes in it. 
     * @see java.sql.Connection#TRANSACTION_READ_COMMITTED 
     */ 
    int ISOLATION_READ_COMMITTED   = Connection.TRANSACTION_READ_COMMITTED; 

同时还有两个对应的方法来得到这样的传播途径和隔离级别
Java代码  收藏代码

    /**
         * Return the propagation behavior.
         * Must return one of the PROPAGATION constants.
         * @see #PROPAGATION_REQUIRED
         * @see org.springframework.transaction.support.TransactionSynchronizationManager#isActualTransactionActive()
         */ 
        int getPropagationBehavior(); 
     
        /**
         * Return the isolation level.
         * Must return one of the ISOLATION constants.
         * <p>Only makes sense in combination with PROPAGATION_REQUIRED or
         * PROPAGATION_REQUIRES_NEW.
         * <p>Note that a transaction manager that does not support custom
         * isolation levels will throw an exception when given any other level
         * than ISOLATION_DEFAULT.
         * @see #ISOLATION_DEFAULT
         */ 
        int getIsolationLevel(); 

这个接口有一个默认的实现DefaultTransactionDefinition。然后它还有子类，比如说
DefaultTransactionAttribute。Spring在判断一个方法是否需要事务体的时候其实是创建一个TransactionAttribute实现的实例.

有了上面的简单介绍就可以进入真正判断是否需要事务的地方了。这个方法在TransactionAspectSupport类里，


Java代码  收藏代码

    /**
         * Create a transaction if necessary.
         * @param method method about to execute
         * @param targetClass class the method is on
         * @return a TransactionInfo object, whether or not a transaction was created.
         * The hasTransaction() method on TransactionInfo can be used to tell if there
         * was a transaction created.
         */ 
        protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) { 
            // If the transaction attribute is null, the method is non-transactional. 
            final TransactionAttribute sourceAttr = 
                    this.transactionAttributeSource.getTransactionAttribute(method, targetClass);//就是在这里判断了这个方法的事务属性 
            TransactionAttribute txAttr = sourceAttr; 
     
            // If no name specified, apply method identification as transaction name. 
            if (txAttr != null && txAttr.getName() == null) { 
                final String name = methodIdentification(method); 
                txAttr = new DelegatingTransactionAttribute(sourceAttr) { 
                    public String getName() { 
                        return name; 
                    } 
                }; 
            } 
     
            TransactionInfo txInfo = new TransactionInfo(txAttr, method); 
    //TransactionInfo是TransactionAspectSupport的一个内部类，它的主要功能是记录方法和对应的事务属性 
            if (txAttr != null) { 
                // We need a transaction for this method 
                if (logger.isDebugEnabled()) { 
                    logger.debug("Getting transaction for " + txInfo.joinpointIdentification()); 
                } 
     
                // The transaction manager will flag an error if an incompatible tx already exists 
                txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));//这个方法要仔细的看 
            } 
            else { 
                // The TransactionInfo.hasTransaction() method will return 
                // false. We created it only to preserve the integrity of 
                // the ThreadLocal stack maintained in this class. 
                if (logger.isDebugEnabled()) 
                    logger.debug("Don't need to create transaction for [" + methodIdentification(method) + 
                            "]: this method isn't transactional"); 
            } 
     
            // 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; 
        } 


TransactionInfo是TransactionAspectSupport的一个内部类，它的主要功能是记录方法和对应的事务属性，在上面这个方法的最后，这个TransactionInfo对象被保存到当前线程中。

而这个方法会在事务拦截器TransactionInterceptor中被调用，TransactionInterceptor实际上是TransactionAspectSupport的子类，看看其中的invoke方法：
Java代码  收藏代码

    // 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; 


这个方法就如同一般的interceptor需要实现的方法一样。只不过在这个方法里判断被反射的方法是否需要事务。

接着我们重点再回头看一下createTransactionIfNecessary方法里的这一句：
txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));
接着我们就应该去看看这个getTransaction方法了，假设我们是使用hibernate3，其他类似。看getTransaction之前我们来看一下这两类和一个接口
接口PlatformTransactionManager
抽象类public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager
类public class HibernateTransactionManager extends AbstractPlatformTransactionManager，很明显，这里有一个方法模板模式。
那我们看一下AbstractPlatformTransactionManager中得getTransaction方法：
Java代码  收藏代码

    public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException { 
            Object transaction = doGetTransaction();//抽象方法，也需要子类实现,这个方法同样很重要 
     
            // Cache debug flag to avoid repeated checks. 
            boolean debugEnabled = logger.isDebugEnabled(); 
            if (debugEnabled) { 
                logger.debug("Using transaction object [" + transaction + "]"); 
            } 
     
            if (definition == null) { 
                // Use defaults if no transaction definition given. 
                definition = new DefaultTransactionDefinition(); 
            } 
     
            if (isExistingTransaction(transaction)) { 
                // Existing transaction found -> check propagation behavior to find out how to behave. 
                return handleExistingTransaction(definition, transaction, debugEnabled); 
            } 
     
            // Check definition settings for new transaction. 
            if (definition.getTimeout() < TransactionDefinition.TIMEOUT_DEFAULT) { 
                throw new InvalidTimeoutException("Invalid transaction timeout", definition.getTimeout()); 
            } 
     
            // No existing transaction found -> check propagation behavior to find out how to behave. 
            if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_MANDATORY) { 
                throw new IllegalTransactionStateException( 
                        "Transaction propagation 'mandatory' but no existing transaction found"); 
            } 
            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); 
            } 
            else { 
                // Create "empty" transaction: no actual transaction, but potentially synchronization. 
                boolean newSynchronization = (this.transactionSynchronization == SYNCHRONIZATION_ALWAYS); 
                return newTransactionStatus(definition, null, false, newSynchronization, debugEnabled, null); 
            } 
        } 

上面的代码很多地方都有解释，所以很好理解，这段代码的关键部分在doBegin(transaction,definition)这里（这是一个抽象方法，子类必须实现这个方法，
具体依赖于抽象，这个是对方法模板模式的一个概括。），前面讲到我们假设是使用hibernate，那么就看看HibernateTransactionManager这个类吧，doBegin里的参数1，transaction其实是HibernateTransactionObject的一个实例，这个实例里主要存放的就是sessionholder，sessionholder里存放的就是开始事务的session和transaction对象,如果之前没有sessionholder存放到线程中，那么这个HibernateTransactionObject的实例的属性其实是空的，这一点可以在doBegin方法的实现中看出来
Java代码  收藏代码

    protected void doBegin(Object transaction, TransactionDefinition definition) { 
            if (getDataSource() != null && TransactionSynchronizationManager.hasResource(getDataSource())) { 
                throw new IllegalTransactionStateException( 
                        "Pre-bound JDBC Connection found - HibernateTransactionManager does not support " + 
                        "running within DataSourceTransactionManager if told to manage the DataSource itself. " + 
                        "It is recommended to use a single HibernateTransactionManager for all transactions " + 
                        "on a single DataSource, no matter whether Hibernate or JDBC access."); 
            } 
     
            Session session = null; 
     
            try { 
                HibernateTransactionObject txObject = (HibernateTransactionObject) transaction; 
                if (txObject.getSessionHolder() == null) { 
                    Interceptor entityInterceptor = getEntityInterceptor(); 
                    Session newSession = (entityInterceptor != null ? 
                            getSessionFactory().openSession(entityInterceptor) : getSessionFactory().openSession()); 
                    if (logger.isDebugEnabled()) { 
                        logger.debug("Opened new Session [" + newSession + "] for Hibernate transaction"); 
                    } 
                    txObject.setSessionHolder(new SessionHolder(newSession), true); 

}//我们看到，如果传进来的transaction中并没有存放sessionholder，那么就新建一个session，放到新的sessionholder中，再放到HibernateTransactionObject的实例中去,顺便说一下，这个变量的名字取得真是差，虽然是Juergen Hoeller写的，也要批一下，搞得别人会以为是Transaction的实例

Java代码  收藏代码

    txObject.getSessionHolder().setSynchronizedWithTransaction(true); 
                session = txObject.getSessionHolder().getSession(); 
     
                Connection con = session.connection(); 
                Integer previousIsolationLevel = DataSourceUtils.prepareConnectionForTransaction(con, definition); 
                txObject.setPreviousIsolationLevel(previousIsolationLevel); 
     
                if (definition.isReadOnly() && txObject.isNewSessionHolder()) { 
                    // Just set to NEVER in case of a new Session for this transaction. 
                    session.setFlushMode(FlushMode.NEVER); 
                }//如果是只读事务，并且sessionholder是新建的，那么就设置hibernate的flushmode为never 
     
                if (!definition.isReadOnly() && !txObject.isNewSessionHolder()) { 
                    // We need AUTO or COMMIT for a non-read-only transaction. 
                    FlushMode flushMode = session.getFlushMode(); 
                    if (FlushMode.NEVER.equals(flushMode)) { 
                        session.setFlushMode(FlushMode.AUTO); 
    //如果session的flushmode是nerver，就设置为auto，因为如果事务定义成非readonly，那么这个session一定是可以flush的 
                        txObject.getSessionHolder().setPreviousFlushMode(flushMode); 
                    } 
                } 
     
                // Add the Hibernate transaction to the session holder. 
                txObject.getSessionHolder().setTransaction(session.beginTransaction())；//开始一个事务，并把这个事务对象放到sessionholder中，随后这个sessionholder会通过threadlocal放到线程中，以供在commit时使用 
     
                // Register transaction timeout. 
                if (definition.getTimeout() != TransactionDefinition.TIMEOUT_DEFAULT) { 
                    txObject.getSessionHolder().setTimeoutInSeconds(definition.getTimeout());//设置超时时间,如果其超时时间为-1，则不进行设置，如果不是-1，那么超时时间是这样设置的new Date(System.currentTimeMillis() + millis*1000);既程序员在配置文件中指定的其实是秒数 
                } 
     
                // Register the Hibernate Session's JDBC Connection for the DataSource, if set. 
                if (getDataSource() != null) { 
                    ConnectionHolder conHolder = new ConnectionHolder(con); 
                    if (definition.getTimeout() != TransactionDefinition.TIMEOUT_DEFAULT) { 
                        conHolder.setTimeoutInSeconds(definition.getTimeout()); 
                    } 
                    if (logger.isDebugEnabled()) { 
                        logger.debug("Exposing Hibernate transaction as JDBC transaction [" + con + "]"); 
                    } 
                    TransactionSynchronizationManager.bindResource(getDataSource(), conHolder); 
                    txObject.setConnectionHolder(conHolder); 
                } 
     
                // Bind the session holder to the thread. 
                if (txObject.isNewSessionHolder()) { 
                    TransactionSynchronizationManager.bindResource(getSessionFactory(), txObject.getSessionHolder());//如果是新的sessionholder则绑定到线程。这样在进入方法栈中的下一个方法时就能得到整个sessionholder了，connectionholder亦是如此 
                } 
            } 
    catch (Exception ex) { 
                SessionFactoryUtils.releaseSession(session, getSessionFactory());//如果抛出异常就释放这个session,这个操作还会在后面出现 
                throw new CannotCreateTransactionException("Could not open Hibernate Session for transaction", ex); 
            } 
        } 

通过以上对代码的注释可以知道，如果给service设置声明式事务管理，假设事务传播途径为required，然后一个service调用另一个service时，他们其实是共用一个session，原则是没有就创建，有就不创建，并返回之前已创建的session和transaction。也就是说spring通过threadlocal把session和对应的transaction放到线程之中，保证了在整个方法栈的任何一个地方都能得到同一个session和transaction。
所以如果你的方法在事务体之内，那么你只要通过hibernatesupportdao或者hibernatetemplate来得到session的话，那这个session一定是开始事务的那个session，这个得到session的主要方法在SessionFactoryUtils里，我们来看一下
（这里还有一个小细节，public abstract class SessionFactoryUtils ，Juergen Hoeller在写工具类的时候为了不能让其有实例使用的是abstract，而我们一般的做法是final类加private的构造方法，看上去不怎么雅观,看看源代码还是能学习到不少写代码的技巧的,这里还有一个插曲，上次feiing还说java为什么不能弄成final和abstract同时存在呢，这样就可以确保既不会有实例产生，也不能继承了，呵呵）
在SessionFactoryUtils的doGetSession里写到，如果当前线程有绑定session，则返回这个session，如果没有绑定session，则看是否允许创建（既allowCreate这个参数是true还是false，这个参数将会在很多地方设计到，比如说hibernatetemplate和hibernatedaosupport里都有），如果不允许创建就抛出一个原始的hibernateException，举个例子，如果你没有给某个service方法配置声明式事务管理，而却要在这个service所调用的dao里得到当前得session，这样就会抛这个错了：
Java代码  收藏代码

    if (method.getName().equals("getCurrentSession")) { 
                    // Handle getCurrentSession method: return transactional Session, if any. 
                    try { 
                        return SessionFactoryUtils.doGetSession((SessionFactory) proxy, false); 
    //最后一个参数是false，说明这个方法不能返回一个新的session，没有就抛异常 
                    } 
                    catch (IllegalStateException ex) { 
                        throw new HibernateException(ex.getMessage()); 
                    } 
                } 


到这里事务开始部分基本就结束了
按正常流程，那么接下来就是方法结束commit的问题了。Commit放到下一篇文章里说吧

我会把大家正确得观点不断得加到贴中，使本贴得质量不断提高，共同进步吧，使劲的拍吧

俺写文章得水平是不行的，希望大家也多提提写文章技巧方面的意见

修改：这篇文章的后续篇(spring声明式事务源码解读之事务提交)已经完成：


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

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

正文：

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

    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方法里有这样一个方法吧：
Java代码  收藏代码

    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方法吧：
Java代码  收藏代码

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


再看看transactionManager.getTransaction(txAttr)方法吧：
Java代码  收藏代码

    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：

Java代码  收藏代码

    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是要在业务方法出栈时提交事务，貌似很简单，但是事实是这样的吗？ 我们接着往下看。
Java代码  收藏代码

    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)这个方法吧。
Java代码  收藏代码

    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作用的同学情况第一篇文章），这个方法其实应该放到第一篇文章中讲的，但是想到如果不讲事务提交就讲这个方法好像没有这么贴切，废话少说，我们来看一下吧：
Java代码  收藏代码

    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，所以它根本不会触发这个动作：
Java代码  收藏代码

    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%的内容看上去还是非常容易理解的，如果把这两篇文章认真看过，我相信会有所收获的，剩下的内容需要靠大家自己去挖掘了，因为另剩下的内容可是需要花费很多时间的，因为牵扯的东西实在是太多了，呵呵。最后祝大家阅读愉快，因为我的文笔实在是让大家的眼睛受罪了。