高h禁伦没羞没躁,免费的性开放交友

Spring中事務嵌套這么用一定得注意了！！

2023-04-22 12:52:26 來源：博客園

前言

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

問題描述

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

(相關資料圖)

在類SecondTransactionService定義一個簡單接口transaction2，插入一個用戶，同時必然會拋出錯誤

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

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

@Override@Transactional(rollbackFor = Exception.class)public void transaction1() {    System.out.println("do transaction1 .......");    try {        // 調(diào)用另外一個事務，try catch住        secondTransactionService.transaction2();    } catch (Exception e) {        e.printStackTrace();    }    // 插入當前用戶tx1    User user = new User("tx1", "111", 18);    userService.insertUser(user);}

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

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

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

問題結果

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

同時控制臺也報錯了，報錯原因是：org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

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

原因追溯

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

controller.testNestedTx()   ||   / FirstTransactionService.transaction1()   REQUIRED隔離級別       ||        ||        || 捕獲異常，提交事務，出錯啦       / || FirstTransactionService.transaction2()   REQUIRED隔離級別       || ||        || 拋出異常,標記事務為rollback only       =======================

事務的隔離級別為REQUIRED，那么發(fā)現(xiàn)沒有事務開啟一個事務操作，有的話，就合并到這個事務中，所以transaction1()、transaction2()是在同一個事務中。transaction2()拋出異常，那么事務會被標記為rollback only, 源碼如下所示：transaction1()由于try catch 異常，正常運行，想必就要可以提交事務了，在提交事務的時候，會檢查rollback標記，如果是true, 這時候就會拋出上面的異常了。源碼如下圖所示：

這下，是不是很清楚知道報錯的原因了，那想想該怎么處理呢？

解決之道

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

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

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

前面提到了事務的傳播機制，我們再看都有哪幾種。

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

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

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

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