xhchc

          危波帆墻,笑談只在桃花上;與誰(shuí)共尚,風(fēng)吹萬(wàn)里浪; 相依相偎,不做黃泉想;莫惆悵,碧波潮生,一蕭自狂放……

           

          Spring聲明式事務(wù)管理源碼解讀之事務(wù)提交(轉(zhuǎn))

          簡(jiǎn)介:上次說(shuō)到spring聲明式事務(wù)管理的事務(wù)開(kāi)始部分,按流程來(lái)講,下面應(yīng)該提交事務(wù)了, spring的聲明式事務(wù)管理其實(shí)是比較復(fù)雜的,事實(shí)上這種復(fù)雜性正是由于事務(wù)本身的復(fù)雜性導(dǎo)致的,如果能用兩三句話(huà)就把這部分內(nèi)容說(shuō)清楚是不現(xiàn)實(shí)的,也是不成熟的,而我對(duì)這部分的理解也可能是不全面的,還是那句話(huà),希望大家和我一起把本貼的質(zhì)量提交起來(lái)。
          在下面的文章中,我講會(huì)多次提到第一篇文章,第一篇文章的地址是:http://www.javaeye.com/topic/87426
          如果要理解事務(wù)提交的話(huà),理解事務(wù)開(kāi)始是一個(gè)前提條件,所以請(qǐng)先看第一篇文章,再來(lái)看這篇
          如果你仔細(xì)看下去,我想肯定是有很多收獲,因?yàn)槲覀兇_實(shí)能從spring的代碼和思想中學(xué)到很多東西。

          正文:

          其實(shí)俺的感覺(jué)就是事務(wù)提交要比事務(wù)開(kāi)始復(fù)雜,看事務(wù)是否提交我們還是要回到TransactionInterceptor類(lèi)的invoke方法
          Java代碼 復(fù)制代碼
          1. public Object invoke(MethodInvocation invocation) throws Throwable {   
          2.         // Work out the target class: may be <code>null</code>.   
          3.         // The TransactionAttributeSource should be passed the target class   
          4.         // as well as the method, which may be from an interface   
          5.         Class targetClass = (invocation.getThis() != null) ? invocation.getThis().getClass() : null;   
          6.            
          7.         // Create transaction if necessary.   
          8.         TransactionInfo txInfo = createTransactionIfNecessary(invocation.getMethod(), targetClass);   
          9.   
          10.         Object retVal = null;   
          11.         try {   
          12.             // This is an around advice.   
          13.             // Invoke the next interceptor in the chain.   
          14.             // This will normally result in a target object being invoked.   
          15.             retVal = invocation.proceed();   
          16.         }   
          17.         catch (Throwable ex) {   
          18.             // target invocation exception   
          19.             doCloseTransactionAfterThrowing(txInfo, ex);   
          20.             throw ex;   
          21.         }   
          22.         finally {   
          23.             doFinally(txInfo);//業(yè)務(wù)方法出棧后必須先執(zhí)行的一個(gè)方法   
          24.         }   
          25.         doCommitTransactionAfterReturning(txInfo);   
          26.         return retVal;   
          27.     }  

          其中的doFinally(txInfo)那一行很重要,也就是說(shuō)不管如何,這個(gè)doFinally方法都是要被調(diào)用的,為什么它這么重要呢,舉個(gè)例子:
          我們還是以propregation_required來(lái)舉例子吧,假設(shè)情況是這樣的,AService中有一個(gè)方法調(diào)用了BService中的,這兩個(gè)方法都處在事務(wù)體之中,他們的傳播途徑都是required。那么調(diào)用開(kāi)始了,AService的方法首先入方法棧,并創(chuàng)建了TransactionInfo的實(shí)例,接著B(niǎo)Service的方法入棧,又創(chuàng)建了一個(gè)TransactionInfo的實(shí)例,而重點(diǎn)要說(shuō)明的是TransactionInfo是一個(gè)自身關(guān)聯(lián)的內(nèi)部類(lèi),第二個(gè)方法入棧時(shí),會(huì)給新創(chuàng)建的TransactionInfo的實(shí)例設(shè)置一個(gè)屬性,就是TransactionInfo對(duì)象中的private TransactionInfo oldTransactionInfo;屬性,這個(gè)屬性表明BService方法的創(chuàng)建的TransactionInfo對(duì)象是有一個(gè)old的transactionInfo對(duì)象的,這個(gè)oldTransactionInfo對(duì)象就是AService方法入棧時(shí)創(chuàng)建的TransactionInfo對(duì)象,我們還記得在createTransactionIfNecessary方法里有這樣一個(gè)方法吧:
          Java代碼 復(fù)制代碼
          1. protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {   
          2.                 // We always bind the TransactionInfo to the thread, even if we didn't create   
          3.         // a new transaction here. This guarantees that the TransactionInfo stack   
          4.         // will be managed correctly even if no transaction was created by this aspect.   
          5.         txInfo.bindToThread();   
          6.         return txInfo;   
          7.     }   
          8.   
          9. 就是這個(gè)bindToThread()方法在作怪:   
          10. private void bindToThread() {   
          11.             // Expose current TransactionStatus, preserving any existing transactionStatus for   
          12.             // restoration after this transaction is complete.   
          13.             oldTransactionInfo = (TransactionInfo) currentTransactionInfo.get();   
          14.             currentTransactionInfo.set(this);   
          15.         }  

          如果當(dāng)前線(xiàn)程中已經(jīng)有了一個(gè)TransactionInfo,則拿出來(lái)放到新建的transactionInfo對(duì)象的oldTransactionInfo屬性中,然后再把新建的TransactionInfo設(shè)置到當(dāng)前線(xiàn)程中。

          這里有一個(gè)概念要搞清楚,就是TransactionInfo對(duì)象并不是表明事務(wù)狀態(tài)的對(duì)象,表明事務(wù)狀態(tài)的對(duì)象是TransactionStatus對(duì)象,這個(gè)對(duì)象同樣是TransactionInfo的一個(gè)屬性(這一點(diǎn),我在前面一篇文章中并沒(méi)有講清楚)。

          接下來(lái)BService中的那個(gè)方法返回,那么該它退棧了,它退棧后要做的就是doFinally方法,即把它的oldTransactionInfo設(shè)置到當(dāng)前線(xiàn)程中(這個(gè)TransactionInfo對(duì)象顯然就是AService方法入棧時(shí)創(chuàng)建的,怎么現(xiàn)在又要設(shè)置到線(xiàn)程中去呢,原因就是BService的方法出棧時(shí)并不提交事務(wù),因?yàn)锽Service的傳播途徑是required,所以要把棧頂?shù)姆椒ㄋ鶆?chuàng)建transactioninfo給設(shè)置到當(dāng)前線(xiàn)程中),即調(diào)用AService的方法時(shí)所創(chuàng)建的TransactionInfo對(duì)象。那么在AServie的方法出棧時(shí)同樣會(huì)設(shè)置TransactionInfo對(duì)象的oldTransactionInfo到當(dāng)前線(xiàn)程,這時(shí)候顯然oldTransactionInfo是空的,但AService中的方法會(huì)提交事務(wù),所以它的oldTransactionInfo也應(yīng)該是空了。

          在這個(gè)小插曲之后,么接下來(lái)就應(yīng)該是到提交事務(wù)了,之前在AService的方法出棧時(shí),我們拿到了它入棧時(shí)創(chuàng)建的TransactionInfo對(duì)象,這個(gè)對(duì)象中包含了AService的方法事務(wù)狀態(tài)。即TransactionStatus對(duì)象,很顯然,太顯然了,事務(wù)提交中的任何屬性都和事務(wù)開(kāi)始時(shí)的創(chuàng)建的對(duì)象息息相關(guān),這個(gè)TransactionStatus對(duì)象哪里來(lái)的,我們?cè)倩仡^看看createTransactionIfNessary方法吧:
          Java代碼 復(fù)制代碼
          1. protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {   
          2.             txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));   
          3.         }  

          再看看transactionManager.getTransaction(txAttr)方法吧:
          Java代碼 復(fù)制代碼
          1. public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {   
          2.            
          3.         else if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||   
          4.                 definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||   
          5.             definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {   
          6.             if (debugEnabled) {   
          7.                 logger.debug("Creating new transaction with name [" + definition.getName() + "]");   
          8.             }   
          9.             doBegin(transaction, definition);   
          10.             boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);   
          11.             return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);//注意這里的返回值,返回的就是一個(gè)TransactionStatus對(duì)象,這個(gè)對(duì)象表明了一個(gè)事務(wù)的狀態(tài),比如說(shuō)是否是一個(gè)新的事務(wù),事務(wù)是否已經(jīng)結(jié)束,等等,這個(gè)對(duì)象是非常重要的,在事務(wù)提交的時(shí)候還是會(huì)用到它的。        }   
          12.             }   
          13.     }  

          還有一點(diǎn)需要說(shuō)明的是,AService的方法在執(zhí)行之前創(chuàng)建的transactionstatus確實(shí)是通過(guò)這個(gè)方法創(chuàng)建的,但是,BService的方法在執(zhí)行之前創(chuàng)建transactionstatus的方法就與這個(gè)不一樣了,下面會(huì)有詳解。

          回顧了事務(wù)開(kāi)始時(shí)所調(diào)用的方法之后,是不是覺(jué)得現(xiàn)在對(duì)spring如何處理事務(wù)越來(lái)越清晰了呢。由于這么幾個(gè)方法的調(diào)用,每個(gè)方法入棧之前它的事務(wù)狀態(tài)就已經(jīng)被設(shè)置好了。這個(gè)事務(wù)狀態(tài)就是為了在方法出棧時(shí)被調(diào)用而準(zhǔn)備的。

          讓我們?cè)俅位氐紹Service中的方法出棧的那個(gè)時(shí)間段,看看spring都做了些什么,我們知道,后入棧的肯定是先出棧,BService中的方法后入棧,拿它肯定要先出棧了,它出棧的時(shí)候是要判斷是否要提交事務(wù),釋放資源的,讓我們來(lái)看看TransactionInterceptor的invoke的最后那個(gè)方法doCommitTransactionAfterReturning:

          Java代碼 復(fù)制代碼
          1. protected void doCommitTransactionAfterReturning(TransactionInfo txInfo) {   
          2.         if (txInfo != null && txInfo.hasTransaction()) {   
          3.             if (logger.isDebugEnabled()) {   
          4.                 logger.debug("Invoking commit for transaction on " + txInfo.joinpointIdentification());   
          5.             }   
          6.             this.transactionManager.commit(txInfo.getTransactionStatus());   
          7. //瞧:提交事務(wù)時(shí)用到了表明事務(wù)狀態(tài)的那個(gè)TransactionStatus對(duì)象了。   
          8.         }   
          9.     }  

          看這個(gè)方法的名字就知道spring是要在業(yè)務(wù)方法出棧時(shí)提交事務(wù),貌似很簡(jiǎn)單,但是事實(shí)是這樣的嗎? 我們接著往下看。
          Java代碼 復(fù)制代碼
          1. public final void commit(TransactionStatus status) throws TransactionException {   
          2.         DefaultTransactionStatus defStatus = (DefaultTransactionStatus) status;   
          3.   
          4.         if (defStatus.isCompleted()) {   
          5.             throw new IllegalTransactionStateException(   
          6.                     "Transaction is already completed - do not call commit or rollback more than once per transaction");   
          7.         }   
          8.         if (defStatus.isLocalRollbackOnly()) {   
          9.             if (defStatus.isDebug()) {   
          10.                 logger.debug("Transactional code has requested rollback");   
          11.             }   
          12.             processRollback(defStatus);   
          13.             return;   
          14.         }   
          15.         if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {   
          16.             if (defStatus.isDebug()) {   
          17.                 logger.debug("Global transaction is marked as rollback-only but transactional code requested commit");   
          18.             }   
          19.             processRollback(defStatus);   
          20.             throw new UnexpectedRollbackException(   
          21.                     "Transaction has been rolled back because it has been marked as rollback-only");   
          22.         }   
          23.   
          24.         processCommit(defStatus);   
          25.     }  

          上面這段代碼就是transactionmanager中的commit,但是看上去,它又把自己的職責(zé)分配給別人了,從代碼里我們看到,如果事務(wù)已經(jīng)結(jié)束了就拋異常,如果事務(wù)是rollbackonly的,那么就rollback吧,但是按照正常流程,我們還是想來(lái)看一下,事務(wù)的提交,就是processCommit(status)這個(gè)方法吧。
          Java代碼 復(fù)制代碼
          1. private void processCommit(DefaultTransactionStatus status) throws TransactionException {   
          2.         try {   
          3.             boolean beforeCompletionInvoked = false;   
          4.             try {   
          5.                 triggerBeforeCommit(status);   
          6.                 triggerBeforeCompletion(status);   
          7.                 beforeCompletionInvoked = true;   
          8.                 if (status.hasSavepoint()) {   
          9.                     if (status.isDebug()) {   
          10.                         logger.debug("Releasing transaction savepoint");   
          11.                     }   
          12.                     status.releaseHeldSavepoint();   
          13.                 }   
          14.                 else if (status.isNewTransaction()) {//這個(gè)判斷非常重要,下面會(huì)詳細(xì)講解這個(gè)判斷的作用   
          15.                     if (status.isDebug()) {   
          16.                         logger.debug("Initiating transaction commit");   
          17.                     }   
          18.                     boolean globalRollbackOnly = status.isGlobalRollbackOnly();   
          19.                     doCommit(status);   
          20.                     // Throw UnexpectedRollbackException if we have a global rollback-only   
          21.                     // marker but still didn't get a corresponding exception from commit.   
          22.                     `````````````````````   
          23.     }  

          我們注意到,在判斷一個(gè)事務(wù)是否是新事務(wù)之前還有一個(gè)status.hasSavepoint()的判斷,我認(rèn)為這個(gè)判斷事實(shí)上就是嵌套事務(wù)的判斷,即判斷這個(gè)事務(wù)是否是嵌套事務(wù),如果不是嵌套事務(wù),則再判斷它是否是一個(gè)新事務(wù),下面這段話(huà)就非常重要了,BService的中的方法是先出棧的,也就是說(shuō)在調(diào)用BService之前的創(chuàng)建的那個(gè)事務(wù)狀態(tài)對(duì)象在這里要先被判斷,但是由于在調(diào)用BService的方法之前已經(jīng)創(chuàng)建了一個(gè)Transaction和Session(假設(shè)我們使用的是hibernate3),這時(shí)候在創(chuàng)建第二個(gè)TransactionInfo(再?gòu)?qiáng)調(diào)一下吧,TransactionInfo并不是Transaction,Transaction是真正的事務(wù)對(duì)象,TransactionInfo只不過(guò)是一個(gè)輔助類(lèi)而已,用來(lái)記錄一系列狀態(tài)的輔助類(lèi))的TransactionStatus的時(shí)候就會(huì)進(jìn)入下面這個(gè)方法(當(dāng)然在這之前會(huì)判斷一下當(dāng)前線(xiàn)程中是否已經(jīng)有了一個(gè)SessionHolder對(duì)象,不清楚SessionHolder作用的同學(xué)情況第一篇文章),這個(gè)方法其實(shí)應(yīng)該放到第一篇文章中講的,但是想到如果不講事務(wù)提交就講這個(gè)方法好像沒(méi)有這么貼切,廢話(huà)少說(shuō),我們來(lái)看一下吧:
          Java代碼 復(fù)制代碼
          1. private TransactionStatus handleExistingTransaction(   
          2.             TransactionDefinition definition, Object transaction, boolean debugEnabled)   
          3.             throws TransactionException {   
          4.   
          5.         if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NEVER) {   
          6.             throw new IllegalTransactionStateException(   
          7.                     "Transaction propagation 'never' but existing transaction found");   
          8.         }   
          9.   
          10.         if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NOT_SUPPORTED) {   
          11.             if (debugEnabled) {   
          12.                 logger.debug("Suspending current transaction");   
          13.             }   
          14.             Object suspendedResources = suspend(transaction);   
          15.             boolean newSynchronization = (this.transactionSynchronization == SYNCHRONIZATION_ALWAYS);   
          16.             return newTransactionStatus(   
          17.                     definition, nullfalse, newSynchronization, debugEnabled, suspendedResources);   
          18.         }   
          19.   
          20.         if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW) {   
          21.             if (debugEnabled) {   
          22.                 logger.debug("Suspending current transaction, creating new transaction with name [" +   
          23.                         definition.getName() + "]");   
          24.             }   
          25.             Object suspendedResources = suspend(transaction);   
          26.             doBegin(transaction, definition);   
          27.             boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);   
          28.             return newTransactionStatus(   
          29.                     definition, transaction, true, newSynchronization, debugEnabled, suspendedResources);   
          30.         }   
          31.   
          32.         if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {   
          33.             if (!isNestedTransactionAllowed()) {   
          34.                 throw new NestedTransactionNotSupportedException(   
          35.                         "Transaction manager does not allow nested transactions by default - " +   
          36.                         "specify 'nestedTransactionAllowed' property with value 'true'");   
          37.             }   
          38.             if (debugEnabled) {   
          39.                 logger.debug("Creating nested transaction with name [" + definition.getName() + "]");   
          40.             }   
          41.             if (useSavepointForNestedTransaction()) {   
          42.                 // Create savepoint within existing Spring-managed transaction,   
          43.                 // through the SavepointManager API implemented by TransactionStatus.   
          44.                 // Usually uses JDBC 3.0 savepoints. Never activates Spring synchronization.   
          45.                 DefaultTransactionStatus status =   
          46.                         newTransactionStatus(definition, transaction, falsefalse, debugEnabled, null);   
          47.                 status.createAndHoldSavepoint();   
          48.                 return status;   
          49.             }   
          50.             else {   
          51.                 // Nested transaction through nested begin and commit/rollback calls.   
          52.                 // Usually only for JTA: Spring synchronization might get activated here   
          53.                 // in case of a pre-existing JTA transaction.   
          54.                 doBegin(transaction, definition);   
          55.                 boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);   
          56.                 return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);   
          57.             }   
          58.         }   
          59.   
          60.         // Assumably PROPAGATION_SUPPORTS.   
          61.         if (debugEnabled) {   
          62.             logger.debug("Participating in existing transaction");   
          63.         }   
          64.         boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);   
          65.         return newTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null);   
          66.     }  

          我們看到這個(gè)方法其實(shí)很明了,就是什么樣的傳播途徑就創(chuàng)建什么樣的transactionstatus,這個(gè)方法是在事務(wù)開(kāi)始時(shí)被調(diào)用的,拿到我們之前舉的例子中來(lái)看下,我們就恍然大悟了,原來(lái),如果之前已經(jīng)創(chuàng)建過(guò)事務(wù),那個(gè)這個(gè)新建的transactionstauts就不應(yīng)該是屬于一個(gè)newTransaction了,所以第3個(gè)參數(shù)就是false了。

          也就是說(shuō),在BService的方法出棧要要執(zhí)行processcommit,但是由于BService的那個(gè)TransactionStatus不是一個(gè)newTransaction,所以它根本不會(huì)觸發(fā)這個(gè)動(dòng)作:
          Java代碼 復(fù)制代碼
          1. else if (status.isNewTransaction()) {//這個(gè)判斷非常重要,下面會(huì)詳細(xì)講解這個(gè)判斷的作用   
          2.                     if (status.isDebug()) {   
          3.                         logger.debug("Initiating transaction commit");   
          4.                     }   
          5. boolean globalRollbackOnly = status.isGlobalRollbackOnly();   
          6.                     doCommit(status);   
          7. }  

          也就是說(shuō)在BService的方法出棧后,事務(wù)是不會(huì)提交的。這完全符合propragation_required的模型。
          而在AService的方法出棧后,AService的方法所對(duì)應(yīng)的那個(gè)TransactionStatus對(duì)象的newTransaction屬性是為true的,即它會(huì)觸發(fā)上面這段代碼,進(jìn)行真正的事務(wù)提交。讓我們回想一下AService方法入棧之前創(chuàng)建TransactionStatus對(duì)象的情形吧:
          newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);看到第3個(gè)參數(shù)為true沒(méi)有。

          那么事務(wù)該提交了吧,事務(wù)的提交我想使用過(guò)hibernate的人都知道怎么提交了:
          txObject.getSessionHolder().getTransaction().commit();
          從當(dāng)前線(xiàn)程中拿到SessionHolder,再拿到開(kāi)始事務(wù)的那個(gè)Transaction對(duì)象,然后再commit事務(wù)。在沒(méi)有用spring之前,我們經(jīng)常這么做。呵呵。

          好吧,我已經(jīng)說(shuō)到了spring聲明式事務(wù)管理的70%到80%的內(nèi)容了,這70%到80%的內(nèi)容看上去還是非常容易理解的,如果把這兩篇文章認(rèn)真看過(guò),我相信會(huì)有所收獲的,剩下的內(nèi)容需要靠大家自己去挖掘了,因?yàn)榱硎O碌膬?nèi)容可是需要花費(fèi)很多時(shí)間的,因?yàn)闋砍兜臇|西實(shí)在是太多了,呵呵。最后祝大家閱讀愉快,因?yàn)槲业奈墓P實(shí)在是讓大家的眼睛受罪了。

          posted on 2008-04-30 11:48 chu 閱讀(1401) 評(píng)論(0)  編輯  收藏


          只有注冊(cè)用戶(hù)登錄后才能發(fā)表評(píng)論。


          網(wǎng)站導(dǎo)航:
           

          導(dǎo)航

          統(tǒng)計(jì)

          常用鏈接

          留言簿(2)

          隨筆檔案

          我的鏈接

          搜索

          最新評(píng)論

          閱讀排行榜

          評(píng)論排行榜

          主站蜘蛛池模板: 濮阳市| 邯郸市| 伊川县| 莆田市| 西宁市| 山丹县| 纳雍县| 泰来县| 东至县| 儋州市| 重庆市| 上蔡县| 铜梁县| 广安市| 水富县| 资源县| 渝北区| 营山县| 岳池县| 遂溪县| 靖江市| 伊宁市| 邵阳县| 镇赉县| 岚皋县| 永嘉县| 永平县| 潢川县| 沽源县| 平度市| 德江县| 法库县| 雷山县| 三河市| 德钦县| 宜兰市| 太和县| 峡江县| 余庆县| 壤塘县| 广汉市|