Spring事務管理中的異常回滾案例分析

這篇文章主要介紹了Spring事務管理中的異常回滾案例分析的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Spring事務管理中的異常回滾案例分析文章都會有所收獲，下面我們一起來看看吧。

問題場景

某項目系統中，serviceA 中調用的 serviceB ，并且對 serviceB 進行 tryCache

@Service("testAService")
public class TestAServiceImpl implements TestAService {
    @Resource
    private TestAMapper testAMapper;
    @Resource
    private TestBService testBService;
    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    public void saveTestA(TestA entity) {
        testAMapper.insertSelective(entity);
        try {
            testBService.saveTestB(new TestB());
        } catch (Exception e) {
            logger.error("調用B失敗", e);
        }
        // 模擬做其他的數據庫操作事情
        testAMapper.updateSelective(entity);
    }
}

testBService 中模擬拋出異常：

@Service("testBService")
public class TestBServiceImpl mplements TestBService {
    @Resource
    private TestBMapper testBMapper;
    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    @Override
    public void saveTestB(TestB entity) {
        testBMapper.insertSelective(entity);
        throw new RuntimeException("自定義異常");
    }
}

問 在Controller層中調用 TestAService.saveTestA() 會怎么樣？

    @Resource
    private TestAService testAService;
    @ApiOperation(value = "Spring事務嵌套測試")
    @GetMapping("springTransactionTest")
    public ResponseVO<NoBody> springTransactionTest() {
        testAService.saveTestA(new TestA());
        return ResponseVO.success();
    }

答案是：

testAService testBService 中的數據庫操作 全部回滾，并且拋出的錯誤異常：

Transaction rolled back because it has been marked as rollback-only

原因是：

testBService.saveTestB 也增加了同樣的事務注解 @Transactional

且事務隔離機制為 “REQUIRED” ，因此 兩方法執行期間為同一個數據庫事務，被同一個Spring事務管理器所管理著。

由于最開始開啟事務者為 testAService.saveTestA，則真正執行回滾操作在 saveTestA 方法中 （Spring 規定了只有新創建的事務才會真正進行提交或回滾），

因此 saveTestB 方法中異常時只設置了當前事務狀態為 RollbackOnly

org.springframework.jdbc.datasource.DataSourceTransactionManager#doSetRollbackOnly

雖然 saveTestA 中 tryCache 了 saveTestB 中的異常，企圖吃掉異常信息讓 saveTestA 中的事務正常提交，但是 saveTestB 里面已經設置了 當前事務狀態為 RollbackOnly， 出現了沖突矛盾！

因此事務全部回滾，并且拋出異常信息：

 Transaction rolled back because it has been marked as rollback-only

Spring 管理事務的原理

首先，事務一般是關系型數據庫中的概念，主要目的就是 保證一系列的增刪改 SQL操作 要么全部成功，要么全部回滾。

MySQL中的事務管理

在MySQL中采用SQL命令進行事務管理：

• START TRANSACTION 或 BEGIN 或 SET autocommit = 0 開啟事務

• 執行 CRUD

• COMMIT 提交事務

• ROLLBACK 回滾事務

這里重點說下 多條SQL在一個事務中，其中有部分SQL執行失敗情況下，最終執行結果是什么

> begin;
> insert_sql1 （insert into test1(id,name)value(1,'aaa')） ;
> insert_sql2 （insert into test2(id,name)value(1,'bbb')） ;
> commit/ rollback;

上面示意代碼，如果 insert_sql1 成功， insert_sql2 失敗時，請問 insert_sql1 最終是否插入成功？

答案是：

首先事務不會馬上回滾， 其次如果 此時執行commit則 insert_sql1 會插入成功 ，如果執行rollback則insert_sql1 會回滾。

那一般事務什么時候自動回滾或者自動提交？這里記錄一下常見場景：

• 如果事務執行中出現 DDL語句( alert create drop truncate等 ) 事務自動 commit;

• 如果事務執行中又開啟了一個事務（又出現 begin; sql命令）事務自動 commit;

• 如果執行SQL的session 中途被關閉（SQL窗口關閉，服務器斷電等） 事務自動 rollback;

JDBC中的事務管理

JDBC中連接數據庫進行事務管理：

• 獲取連接 Connection con = DriverManager.getConnection()

• con.setAutoCommit(true/false); 開啟事務

• 執行CRUD

• con.commit() ; 提交事務

• con.rollback(); 回滾事務

• 關閉連接 conn.close();

JDBC 事務管理的本質還是連接了數據庫執行各類數據庫中開啟關閉事務的SQL命令

Spring中的事務管理

Spring通過自身AOP切面功能，代理各個業務方法調用 JDBC中的方法進行開啟、關閉、提交、回滾事務等操作。

至于嵌套事務、各類傳播機制是如何實現， 這里簡單總結，雖然不能體現Spring 事務操作方面的強大，但可以很快有個大致理解。

Spring 通過 一個Map 存放了當前數據庫連接對象，這是為了解決根據設定的傳播機制 ( propagation ) 決定是否要新開一個事務，新開另外一個事務需要重新申請一個數據庫連接。

Spring 通過 數據庫事務中的 SAVEPOINT 保留點功能實現 嵌套事務的傳播機制。

這里記錄一下一個HTTP請求 從Controller層發起數據庫操作請求到回滾的log日志，用于加強理解：

    @ApiOperation(value = "事務回滾測試")
    @PostMapping("rollbackTest")
    public ResponseVO<NoBody> rollbackTest() {
        // 簡單模擬插入一條記錄
        testAService.saveTestA(new TestA());
        return ResponseVO.success();
    }

[http-nio-9902-exec-5] o.s.web.servlet.DispatcherServlet        : POST "/api/rollbackTest", parameters={}
[http-nio-9902-exec-5] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to com.guzt.main.model.test.web.DbTestController#rollbackTest()
[http-nio-9902-exec-5] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [com.sdjictec.wms.main.model.test.service.impl.TestAServiceImpl.saveTestA]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT,-java.lang.Exception
[http-nio-9902-exec-5] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [com.alibaba.druid.proxy.jdbc.ConnectionProxyImpl@7fec11ca] for JDBC transaction
[http-nio-9902-exec-5] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [com.alibaba.druid.proxy.jdbc.ConnectionProxyImpl@7fec11ca] to manual commit
[http-nio-9902-exec-5] c.s.w.m.m.t.d.T.insertSelective          : ==>  Preparing: INSERT INTO t_test_a ( ID,NAME ) VALUES(?,? )
[http-nio-9902-exec-5] c.s.w.m.m.t.d.T.insertSelective          : ==> Parameters: 1655001437939(String), p4xfy8(String)
[http-nio-9902-exec-5] c.s.w.m.m.t.d.T.insertSelective          : <==    Updates: 1
[http-nio-9902-exec-5] o.s.j.d.DataSourceTransactionManager     : Initiating transaction rollback
[http-nio-9902-exec-5] o.s.j.d.DataSourceTransactionManager     : Rolling back JDBC transaction on Connection [com.alibaba.druid.proxy.jdbc.ConnectionProxyImpl@7fec11ca]
[http-nio-9902-exec-5] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [com.alibaba.druid.proxy.jdbc.ConnectionProxyImpl@7fec11ca] after transaction
[http-nio-9902-exec-5] c.s.w.m.c.p.context.CurrentUserContext   : CurrentUserContext remove CurrentUserVO...
[http-nio-9902-exec-5] c.s.w.m.f.a.CurrentUserContextAspect     : CurrentUserContextAspect doAfterThrowing  CurrentUserContext.remove()...
[http-nio-9902-exec-5] .m.m.a.ExceptionHandlerExceptionResolver : Using @ExceptionHandler com.guzt.main.framework.exception.GlobalExceptionHandler#handleBusinessException(BusinessException)
[http-nio-9902-exec-5] c.s.w.m.f.e.GlobalExceptionHandler       : BusinessException -- errorCode：E5111 errorMsg：模擬數據庫操作異常，主鍵重復
[http-nio-9902-exec-5] m.m.a.RequestResponseBodyMethodProcessor : Using 'application/json', given [*/*] and supported [application/json, application/json, application/*+json, application/json, application/*+json, application/cbor]
[http-nio-9902-exec-5] m.m.a.RequestResponseBodyMethodProcessor : Writing [ResponseVO(code=-1, message=模擬數據庫操作異常，主鍵重復, data={"errorBody":"","bussinessCode":"E5111","extraMsg":""})]
[http-nio-9902-exec-5] .m.m.a.ExceptionHandlerExceptionResolver : Resolved [com.guzt.starter.common.exception.BusinessException: errorCode=E5111, errorMsg=FAIL]
[http-nio-9902-exec-5] o.s.web.servlet.DispatcherServlet        : Completed 200 OK

主要的步驟：

Creating new transaction

DataSourceTransactionManager 根據 TransactionDefinition 創建 TransactionStatus 對象，準備開啟事務Acquired Connection for JDBC transaction

通過數據庫連接池 申領一個數據庫連接Switching JDBC Connection to manual commit

開啟事務，底層是通過JDBC執行 SET autocommit = 0; Initiating transaction rollback

準備回滾事務，修改 TransactionStatus 狀態為回滾Rolling back JDBC transaction

回滾事務 ，底層是通過JDBC執行 rollback; SET autocommit = 1;Releasing JDBC Connection

釋放數據庫連接，最后是關閉了數據庫連接，底層調用了 JDBC Connection.close()

Spring中的事務接口

上面日志中提到了 TransactionDefinition TransactionStatus 等接口，這里也順便總結一下Spring事務中重要的幾個接口。

至于具體功能流程，這里不討論，自行看源碼，多debug即可明白。

到底回滾還是不回滾

本次討論重點就是 Spring的事務管理中，遇到了程序異常到底會不會回滾？

簡明答案

執行事務的方法如果感知到了異常則將回滾事務

什么是執行事務的方法

一般方法上增加了 @Transactional 注解或 其他Spring事務支持的方式AOP代理了的方法

  @Transactional
   public void saveTestA(TestA entity) {
        業務代碼
   }

什么情況下異常被感知

被Spring事務AOP所代理的業務方法執行時出現異常，且異常類在Spring事務回滾范圍內的將被調用方法所感知。

默認Spring只對 unchecked Exception 進行回滾，一般手動設定全部異常（rollbackFor = Exception.class）

什么情況下異常不被感知

一般這是討論事務不生效的場景。

• 方法訪問修飾符非public

• 法拋出的異常不是spring的事務支持的異常

• 被 Try-Cache 捕獲且不再向外拋出例如下面的場景代碼：

   @Transactional
   public void saveTestA(TestA entity) {
     try{
        業務代碼
     } catch (Exception e) {
         logger.error("內部消化異常，不往外拋", e);
     }
   }

注解所在的類沒有被Spring 事務AOP代理

這種場景問題最隱蔽，一般需要有經驗或者多次debug才能發現

同一個類里面方法互相調用，一般建議采用 SpringUtil.getBean(this.getClass()).xxxx事務方法()

某些策略模式場景，需要將service對象放到一個 Map<String, Service>中 ,如果是自行放置，則對象必須是 代理對象而非 this對象，建議采用 SpringUtil.getBean(this.getClass()) 對象。

參考代碼：

public class WxinOrderTypeServiceImpl implements OrderTypeService {
  @PostConstruct
  public void init() {
      ORDER_TYPE_SERVICE.put("orderTypeKey", SpringUtil.getBean(this.getClass());
  }
  @Transactional(rollbackFor = Exception.class)
  @Override
  public void saveOrder(Order order)
    logger.info("微信訂單");
  }
}

上面代碼意思是，將Spring代理的對象 WxinOrderTypeServiceImpl$Cjlibxxxx 放置到策略map ORDER_TYPE_SERVICE中去，如果用 this （ ORDER_TYPE_SERVICE.put("orderTypeKey",this)） 則事務不生效，因為this雖然也在Spring beanFactory中但沒有被事務AOP所代理，因此用this 會不生效。

備注： SpringUtil 其實就是實現了接口 ApplicationContextAware 獲得ApplicationContext，ApplicationContext 中有 getBean方法，當然SpringBoot 可以在業務類里面直接注入 ApplicationContext

@Autowired
ApplicationContext applicationContext;

數據庫本身不支持事務

如果使用MySQL且存儲引擎是MyISAM，則事務是不起作用的

異常被感知后Spring做些什么

異常被感知后，Spring將會做回滾或更新TransactionStatus的狀態（doSetRollbackOnly）.

一旦TransactionStatus 被打上了 RollbackOnly標志后，那么不管中間的業務代碼是什么 都會拋出異常進行全部事務回滾。

那么什么時候 不做回滾只更新 TransactionStatus 為 RollbackOnly？

參見文章一開始的業務代碼，同屬于一個事務中（Propagation.REQUIRED）的多個執行事務方法（業務代碼中嵌套調用其他service方法），如果不是首次開啟事務的那個方法則都只會更新 TransactionStatus 為 RollbackOnly，事務的提交回滾由首次事務開啟的那個方法執行

回滾程度是多少

事務回滾到哪一個程度，是全部嵌套調用的方法都回滾還是部分方法回滾，這里主要是由Spring的事務傳播機制功能控制。

關于“Spring事務管理中的異常回滾案例分析”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“Spring事務管理中的異常回滾案例分析”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。