更深入理解 Spring 事務(wù)。

用戶注冊完成后，需要給該用戶登記一門PUA必修課，并更新該門課的登記用戶數(shù)。
為此，我添加了兩個表。
課程表 course，記錄課程名稱和注冊的用戶數(shù)。

用戶選課表 user_course，記錄用戶表 user 和課程表 course 之間的多對多關(guān)聯(lián)。

同時為課程表初始化了一條課程信息

接下來我們完成用戶的相關(guān)操作，主要包括兩部分：

新增用戶選課記錄

課程登記學(xué)生數(shù) + 1

新增業(yè)務(wù)類 CourseService實(shí)現(xiàn)相關(guān)業(yè)務(wù)邏輯，分別調(diào)用了上述方法保存用戶與課程的關(guān)聯(lián)關(guān)系，并給課程注冊人數(shù)+1

為避免注冊課程的業(yè)務(wù)異常導(dǎo)致用戶信息無法保存，這里 catch 注冊課程方法中拋出的異常。希望當(dāng)注冊課程發(fā)生錯誤時，只回滾注冊課程部分，保證用戶信息依然正常。

為驗(yàn)證異常是否符合預(yù)期，在 regCourse() 里拋一個注冊失敗異常：

執(zhí)行代碼：

注冊失敗部分的異常符合預(yù)期，但是后面又多了一個這樣的錯誤提示：Transaction rolled back because it has been marked as rollback-only


最后用戶和選課的信息都被回滾了，顯然這不符預(yù)期。
期待結(jié)果是即便內(nèi)部事務(wù)regCourse()發(fā)生異常，外部事務(wù)saveStudent()俘獲該異常后，內(nèi)部事務(wù)應(yīng)自行回滾，不影響外部事務(wù)。
這是什么原因造成的呢？

源碼解析

偽代碼梳理整個事務(wù)的結(jié)構(gòu)：

整個業(yè)務(wù)包含2層事務(wù)：

• 外層 saveUser() 的事務(wù)
• 內(nèi)層 regCourse() 事務(wù)

Spring聲明式事務(wù)中的propagation屬性，表示對這些方法使用怎樣的事務(wù)，即：
一個帶事務(wù)的方法調(diào)用了另一個帶事務(wù)的方法，被調(diào)用的方法它怎么處理自己事務(wù)和調(diào)用方法事務(wù)之間的關(guān)系。

propagation 有7種配置：

• REQUIRED：默認(rèn)值，如果本來有事務(wù)，則加入該事務(wù)，如果沒有事務(wù)，則創(chuàng)建新的事務(wù)。
• SUPPORTS
• MANDATORY
• REQUIRES_NEW
• NOT_SUPPORTED
• NEVER
• NESTED

因?yàn)椋?/p>

• 在 saveUser() 上聲明了一個外部的事務(wù)，就已經(jīng)存在一個事務(wù)了
• 在propagation值為默認(rèn)REQUIRED時

regCourse() 就會加入到已有的事務(wù)中，兩個方法共用一個事務(wù)。

Spring 事務(wù)處理的核心：

TransactionAspectSupport.invokeWithinTransaction()

protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
      final InvocationCallback invocation) throws Throwable {
 
   TransactionAttributeSource tas = getTransactionAttributeSource();
   final TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);
   final PlatformTransactionManager tm = determineTransactionManager(txAttr);
   final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);
   if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
      // 是否需要創(chuàng)建一個事務(wù)
      TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
      Object retVal = null;
      try {
         // 調(diào)用具體的業(yè)務(wù)方法
         retVal = invocation.proceedWithInvocation();
      }
      catch (Throwable ex) {
         // 當(dāng)發(fā)生異常時進(jìn)行處理
         completeTransactionAfterThrowing(txInfo, ex);
         throw ex;
      }
      finally {
         cleanupTransactionInfo(txInfo);
      }
      // 正常返回時提交事務(wù)
      commitTransactionAfterReturning(txInfo);
      return retVal;
   }
   //......省略非關(guān)鍵代碼.....
}

整個方法完成了事務(wù)的一整套處理邏輯，如下：

• 檢查是否需要創(chuàng)建事務(wù)
• 調(diào)用具體的業(yè)務(wù)方法進(jìn)行處理
• 提交事務(wù)
• 處理異常

當(dāng)前案例是兩個事務(wù)嵌套，外層事務(wù) saveUser()和內(nèi)層事務(wù) regCourse()，每個事務(wù)都會調(diào)用到這個方法。所以，該方法會被調(diào)兩次。

內(nèi)層事務(wù)

當(dāng)捕獲了異常，會調(diào)用

TransactionAspectSupport.completeTransactionAfterThrowing()

進(jìn)行異常處理：

對異常類型做了一些檢查，當(dāng)符合聲明中的定義后，執(zhí)行具體的 rollback 操作，這個操作是通過如下方法完成：

AbstractPlatformTransactionManager rollback()

該回滾實(shí)現(xiàn)負(fù)責(zé)處理正參與到已有事務(wù)集的事務(wù)。委托執(zhí)行Rollback和doSetRollbackOnly。

繼續(xù)調(diào)用

processRollback()

該方法里區(qū)分了三種場景：

• 是否有保存點(diǎn)
• 是否為一個新的事務(wù)
• 是否處于一個更大的事務(wù)中

因?yàn)槟J(rèn)傳播類型REQUIRED，嵌套的事務(wù)并未開啟一個新事務(wù)，所以屬于當(dāng)前事務(wù)處于一個更大事務(wù)中，所以會走到分支1。

如下的判斷條件確定是否設(shè)置為僅回滾：

if (status.isLocalRollbackOnly() ||
	 isGlobalRollbackOnParticipationFailure())

滿足任一，都會執(zhí)行 doSetRollbackOnly()：

isLocalRollbackOnly

默認(rèn) false，當(dāng)前場景為 falseisGlobalRollbackOnParticipationFailure()

所以，就只由該方法來確定了，默認(rèn)值為 true， 即是否回滾交由外層事務(wù)統(tǒng)一決定

條件得到滿足，執(zhí)行

DataSourceTransactionManager#doSetRollbackOnly

最終調(diào)用

DataSourceTransactionObject#setRollbackOnly()

內(nèi)層事務(wù)操作執(zhí)行完畢。

外層事務(wù)

外層事務(wù)中，業(yè)務(wù)代碼就捕獲了內(nèi)層所拋異常，所以該異常不會繼續(xù)往上拋，最后的事務(wù)會在 TransactionAspectSupport.invokeWithinTransaction() 中的

TransactionAspectSupport#commitTransactionAfterReturning()

該方法里執(zhí)行了commit 操作：

AbstractPlatformTransactionManager#commit

當(dāng)滿足 !shouldCommitOnGlobalRollbackOnly() &&defStatus.isGlobalRollbackOnly()，就會回滾，否則繼續(xù)提交事務(wù)：

shouldCommitOnGlobalRollbackOnly()
若發(fā)現(xiàn)事務(wù)被標(biāo)記了全局回滾，且在發(fā)生全局回滾時，判斷是否應(yīng)該提交事務(wù)，這個方法的默認(rèn)返回 false，這里無需關(guān)注

isGlobalRollbackOnly()

該方法最終進(jìn)入

DataSourceTransactionObject#isRollbackOnly()

之前內(nèi)部事務(wù)處理最終調(diào)用到DataSourceTransactionObject#setRollbackOnly()

public void setRollbackOnly() {
   getConnectionHolder().setRollbackOnly();
}

• isRollbackOnly()
• setRollbackOnly()

兩個方法本質(zhì)都是對ConnectionHolder.rollbackOnly屬性標(biāo)志位的存取
但ConnectionHolder則存在于DefaultTransactionStatus#transaction屬性。

綜上：外層事務(wù)是否回滾的關(guān)鍵，最終取決于DataSourceTransactionObject#isRollbackOnly()，該方法返回值正是在內(nèi)層異常時設(shè)置的。
所以最終外層事務(wù)也被回滾，從而在控制臺中打印上述日志。

這就明白了，Spring默認(rèn)事務(wù)傳播屬性為REQUIRED：若已有事務(wù)，則加入該事務(wù)，若無事務(wù)，則創(chuàng)建新事務(wù)，因而內(nèi)外兩層事務(wù)都處于同一事務(wù)。
在 regCourse()中拋異常，并觸發(fā)回滾操作時，這個回滾會繼續(xù)傳播，從而把 saveUser() 也回滾，最終整個事務(wù)都被回滾！

修正

Spring事務(wù)默認(rèn)傳播屬性 REQUIRED，在整個事務(wù)的調(diào)用鏈上，任一環(huán)節(jié)拋異常都會導(dǎo)致全局回滾。

所以只需將傳播屬性改成 REQUIRES_NEW ：

運(yùn)行：

異常正常拋出，注冊課程部分的數(shù)據(jù)沒有保存，但用戶還是正常注冊成功。這意味著此時Spring 只對注冊課程這部分的數(shù)據(jù)進(jìn)行了回滾，并沒有傳播到外層：

當(dāng)子事務(wù)聲明為 Propagation.REQUIRES_NEW 時，在 TransactionAspectSupport.invokeWithinTransaction() 中調(diào)用 createTransactionIfNecessary() 就會創(chuàng)建一個新的事務(wù)，獨(dú)立于外層事務(wù)而在 AbstractPlatformTransactionManager.processRollback() 進(jìn)行 rollback 處理時，因?yàn)?status.isNewTransaction() 會因?yàn)樗幱谝粋€新的事務(wù)中而返回 true，所以它走入到了另一個分支，執(zhí)行了 doRollback() 操作，讓這個子事務(wù)單獨(dú)回滾，不會影響到主事務(wù)。

到此這篇關(guān)于淺談Spring嵌套事務(wù)是怎么回滾的的文章就介紹到這了,更多相關(guān)Spring嵌套事務(wù)回滾內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論