Spring中事務(wù)嵌套這么用一定得注意

前言

最近項(xiàng)目上有一個(gè)使用事務(wù)相對(duì)復(fù)雜的業(yè)務(wù)場(chǎng)景報(bào)錯(cuò)了。在絕大多數(shù)情況下，都是風(fēng)平浪靜，沒有問題。其實(shí)內(nèi)在暗流涌動(dòng)，在有些異常情況下就會(huì)報(bào)錯(cuò)，這種偶然性的問題很有可能就會(huì)在暴露到生產(chǎn)上造成事故，那究竟是怎么回事呢？

問題描述

我們用一個(gè)簡(jiǎn)單的例子模擬下，大家也可以看看下面這段代碼輸出的結(jié)果是什么。

1. 在類SecondTransactionService定義一個(gè)簡(jiǎn)單接口transaction2，插入一個(gè)用戶，同時(shí)必然會(huì)拋出錯(cuò)誤

@Override
@Transactional(rollbackFor = Exception.class)
public void transaction2() {
    System.out.println("do transaction2.....");
    User user = new User("tx2", "111", 18);
    // 插入一個(gè)用戶
    userService.insertUser(user);
    // 跑錯(cuò)了
    throw new RuntimeException();
}

2. 在另外一個(gè)類FirstTransactionService定義一個(gè)接口transaction1，它調(diào)用transaction2方法，同時(shí)做了try catch處理

@Override
@Transactional(rollbackFor = Exception.class)
public void transaction1() {
    System.out.println("do transaction1 .......");
    try {
        // 調(diào)用另外一個(gè)事務(wù)，try catch住
        secondTransactionService.transaction2();
    } catch (Exception e) {
        e.printStackTrace();
    }

    // 插入當(dāng)前用戶tx1
    User user = new User("tx1", "111", 18);
    userService.insertUser(user);
}

3. 定義一個(gè)controller，調(diào)用transaction1方法

@GetMapping("/testNestedTx")
public String testNestedTx() {
    firstTransactionService.transaction1();
    return "success";
}

大家覺得調(diào)用這個(gè)http接口，最終數(shù)據(jù)庫(kù)插入的是幾條數(shù)據(jù)呢？

問題結(jié)果

正確答案是數(shù)據(jù)庫(kù)插入了0條數(shù)據(jù)。

同時(shí)控制臺(tái)也報(bào)錯(cuò)了，報(bào)錯(cuò)原因是：org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

是否和你預(yù)想的一樣呢？你知道是為什么嗎？

原因追溯

其實(shí)原因很簡(jiǎn)單，我們都知道，一個(gè)事務(wù)要么全成功提交事務(wù)，要么失敗全部回滾。如果出現(xiàn)在一個(gè)事務(wù)中部分SQL要回滾，部分SQL要提交，這不就主打的一個(gè)”前后矛盾，精神分裂“嗎？

controller.testNestedTx() 
  || 
  / 
FirstTransactionService.transaction1()   REQUIRED隔離級(jí)別
       || 
       || 
       || 捕獲異常，提交事務(wù)，出錯(cuò)啦
       / || 
FirstTransactionService.transaction2()   REQUIRED隔離級(jí)別
       || || 
       || 拋出異常,標(biāo)記事務(wù)為rollback only
       =======================

1. 事務(wù)的隔離級(jí)別為REQUIRED，那么發(fā)現(xiàn)沒有事務(wù)開啟一個(gè)事務(wù)操作，有的話，就合并到這個(gè)事務(wù)中，所以transaction1()、transaction2()是在同一個(gè)事務(wù)中。
2. transaction2()拋出異常，那么事務(wù)會(huì)被標(biāo)記為rollback only, 源碼如下所示：

3. transaction1()由于try catch異常，正常運(yùn)行，想必就要可以提交事務(wù)了，在提交事務(wù)的時(shí)候，會(huì)檢查rollback標(biāo)記，如果是true, 這時(shí)候就會(huì)拋出上面的異常了。源碼如下圖所示：

這下，是不是很清楚知道報(bào)錯(cuò)的原因了，那想想該怎么處理呢？

解決之道

知道了根本原因之后，是不是解決的方案就很明朗了，我們可以通過調(diào)整事務(wù)的傳播方式分拆多個(gè)事務(wù)管理，或者讓一個(gè)事務(wù)"前后一致"，做一個(gè)誠(chéng)信的好事務(wù)。

• 將try catch放到內(nèi)層事務(wù)中，也就是transaction2()方法中，這樣內(nèi)層事務(wù)會(huì)跟著外部事務(wù)進(jìn)行提交或者回滾。

@Override
    @Transactional(rollbackFor = Exception.class)
    public void transaction2() {
        try {
            System.out.println("do transaction2.....");
            User user = new User("tx2", "111", 18);
            userService.insertUser2(user);
            throw new RuntimeException();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

• 如果希望內(nèi)層事務(wù)拋出異常時(shí)中斷程序執(zhí)行，直接在外層事務(wù)的catch代碼塊中拋出e，這樣同一個(gè)事務(wù)就都會(huì)回滾。
• 如果希望內(nèi)層事務(wù)回滾，但不影響外層事務(wù)提交，需要將內(nèi)層事務(wù)的傳播方式指定為PROPAGATION_NESTED。PROPAGATION_NESTED基于數(shù)據(jù)庫(kù)savepoint實(shí)現(xiàn)的嵌套事務(wù)，外層事務(wù)的提交和回滾能夠控制嵌內(nèi)層事務(wù)，而內(nèi)層事務(wù)報(bào)錯(cuò)時(shí)，可以返回原始savepoint，外層事務(wù)可以繼續(xù)提交。

事務(wù)的傳播機(jī)制

前面提到了事務(wù)的傳播機(jī)制，我們?cè)倏炊加心膸追N。

• PROPAGATION_REQUIRED：加入到當(dāng)前事務(wù)中，如果當(dāng)前沒有事務(wù)，就新建一個(gè)事務(wù)。這是最常見的選擇，也是Spring中默認(rèn)采用的方式。
• PROPAGATION_SUPPORTS：支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就以非事務(wù)方式執(zhí)行。
• PROPAGATION_MANDATORY ：支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就拋出異常。
• PROPAGATION_REQUIRES_NEW：新建一個(gè)事務(wù)，如果當(dāng)前存在事務(wù)，把當(dāng)前事務(wù)掛起。
• PROPAGATION_NOT_SUPPORTED ：以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。
• PROPAGATION_NEVER： 以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。
• PROPAGATION_NESTED ：如果當(dāng)前存在事務(wù)，則在嵌套事務(wù)內(nèi)執(zhí)行。如果當(dāng)前沒有事務(wù)，則進(jìn)行與PROPAGATION_REQUIRED類似的操作。

如何理解PROPAGATION_NESTED的傳播機(jī)制呢，和PROPAGATION_REQUIRES_NEW又有什么區(qū)別呢？我們用一個(gè)例子說明白。

• 定義serviceA.methodA()以PROPAGATION_REQUIRED修飾；
• 定義serviceB.methodB()以表格中三種方式修飾；
• methodA中調(diào)用methodB;

總結(jié)

在我的項(xiàng)目中之所以會(huì)報(bào)“rollback-only”異常的根本原因是代碼風(fēng)格不一致的原因。外層事務(wù)對(duì)錯(cuò)誤的處理方式是返回true或false來告訴上游執(zhí)行結(jié)果，而內(nèi)層事務(wù)是通過拋出異常來告訴上游（這里指外層事務(wù)）執(zhí)行結(jié)果，這種差異就導(dǎo)致了“rollback-only”異常。大家也可以去review自己項(xiàng)目中的代碼，是不是也偷偷犯下同樣的錯(cuò)誤了。