浏览 21360 次
精华帖 (4) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-06-11
*作者:张荣华(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%的内容看上去还是非常容易理解的,如果把这两篇文章认真看过,我相信会有所收获的,剩下的内容需要靠大家自己去挖掘了,因为另剩下的内容可是需要花费很多时间的,因为牵扯的东西实在是太多了,呵呵。最后祝大家阅读愉快,因为我的文笔实在是让大家的眼睛受罪了。 作者:张荣华,未经作者同意不得随意转载! 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-06-12
回头再看这篇文章,觉得写得可能太抽象了,因为没有对transaction有一个大体的概念的话,可能真的不太容易理解,当然本来就清楚的人除外,所以我上网找了一下spring1.2.x的关于transaction部分的uml图
http://opensource.objectsbydesign.com/spring/ 上面这个url是spring的1.2.x的uml图的网址。 对着这个uml图再来看文章,我想会有些帮助 |
|
返回顶楼 | |
发表时间: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设的那个。 |
|
返回顶楼 | |
发表时间:2007-08-16
这个TransactionInfo是一个状态对象,代表每个事务(或者假事务,既在事务体内,但是自己又没有创建事务)的事务属性,它在方法调用前被创建(在声明式事务里是根据配置),在业务方法结束后需要用到它来判断事务是否有事务,有事务那是否提交等等一系列的判断。
引用 然后就直接提交了,没有看到去currentTransactionInfo中去取哪?
没太明白你的意思,当前的TransactionInfo就是在这个invoke方法里啊 |
|
返回顶楼 | |
发表时间: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被使用 - 那为什么要做这样一系列的设置? |
|
返回顶楼 | |
发表时间: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),但是没有看到使用啊? |
|
返回顶楼 | |
发表时间: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的代码,只有在某些情况下才会使用,看注释吧 |
|
返回顶楼 | |
发表时间: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也应该是空了。 |
|
返回顶楼 | |
发表时间: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() };我觉得它这样做就是为了扩展起来方便,否则只有一个元素实在没有必要用数组了 |
|
返回顶楼 | |