歡迎您光臨本站 註冊首頁

Spring聲明式事務管理源碼解讀之事務提交

←手機掃碼閱讀     火星人 @ 2014-03-10 , reply:0

其實我的感覺就是事務提交要比事務開始複雜,看事務是否提交我們還是要回到TransactionInterceptor類的invoke方法:

Java代碼

public Object invoke(MethodInvocation invocation) throws Throwable {   // Work out the target class: may be null.   // 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.PR
OPAGATION_REQUIRED ||
definition.getPropagationBehavior() == TransactionDefinition.PROP
AGATION_REQUIRES_NEW ||
definition.getPropagationBehavior() == TransactionDefinition.PROPAGA
TION_NESTED) {
if (debugEnabled) {
logger.debug("Creating new transaction with name [" definition.
getName() "]");
}


doBegin(transaction, definition);
boolean newSynchronization = (this.transactionSynchronization != SYN
CHRONIZATION_NEVER);
return newTransactionStatus(definition, transaction, true, newSynchro
nization, 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.j
oinpointIdentification());
}
this.transactionManager.commit(txInfo.getTransactionStatus());
//瞧:提交事務時用到了表明事務狀態的那個TransactionStatus對象了.
}
}

看這個方法的名字就知道spring是要在業務方法出棧時提交事務,貌似很簡單,但是事實是這樣的嗎?我們接著往下看.

Java代碼

public final void commit(TransactionStatus status) throws TransactionException {


[火星人 ] Spring聲明式事務管理源碼解讀之事務提交已經有489次圍觀

http://coctec.com/docs/java/show-post-61800.html