本文轉(zhuǎn)載自微信公眾號「 yes的練級攻略」，作者 是Yes呀。轉(zhuǎn)載本文請聯(lián)系 yes的練級攻略公眾號。

成都創(chuàng)新互聯(lián)公司主要從事網(wǎng)站設(shè)計制作、做網(wǎng)站、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)魏縣,十多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

你好，我是yes。

昨天測試說有個 xx 功能用不了，扔給我一個截圖，說有報錯：

報錯信息就是：Transaction rolled back because it has been marked as rollback-only，很好理解：事務(wù)被回滾了，因?yàn)樗呀?jīng)被標(biāo)記了只能回滾。

我一看巧了，這不就是我之前分析過的面試題嗎！

之前的文章我解釋過：這種錯一般發(fā)生在嵌套事務(wù)中，即內(nèi)層事務(wù)出錯，但是由于是否提交事務(wù)的操作由外層事務(wù)觸發(fā)，于是乎內(nèi)層事務(wù)只能做個標(biāo)記，來設(shè)置當(dāng)前事務(wù)只能回滾。

緊接著它想拋出錯誤，但是由于被 try catch 了，于是乎正常執(zhí)行后續(xù)的邏輯，等執(zhí)行到最后，外層要提交事務(wù)了，發(fā)現(xiàn)當(dāng)前事務(wù)已經(jīng)被打了回滾的標(biāo)記，所以提交失敗，報了上面的錯。

具體原理可以看我之前的那篇文章，這里簡單舉例下會出錯的示例代碼：

大致就是下面這個代碼調(diào)用邏輯，有一個 service 標(biāo)記了 @Transcational，采用默認(rèn)的事務(wù)傳播機(jī)制：

緊接著 UserService#insert 調(diào)用了 addressService#errorInvoker，這個方法也標(biāo)記了 @Transcational：

這樣一來，只要 addressService#errorInvoker 的調(diào)用發(fā)生報錯，那么必然能重現(xiàn)上面的報錯信息。

原理很清晰，我不可能犯這個錯。

我信誓旦旦的對測試說：這肯定是老陳寫的 bug，與我無關(guān)！

老陳瞄了我一眼：老子已經(jīng) 2 個月沒碰過那個項目了，你扯犢子呢？

隨后這個老測試直接把更詳細(xì)的報錯扔了過來，咳咳，涉及公司的類名這里不展示的，反正確實(shí)是我的代碼....

但是我還是覺得很不可思議，這部分邏輯是我新寫的，我壓根就沒有使用嵌套事務(wù)?。?/p>

大致的代碼如下：

@Override
    @Transactional(rollbackFor = Exception.class)
    public Boolean xxx(xxx dto) {
        list1 = .....;
        try {
              數(shù)據(jù)庫批量保存list1;
        } catch (Exception e) {
            if (e instanceof DuplicateKeyException) {
                //篩選過濾重復(fù) key 的數(shù)據(jù)
                //打標(biāo)發(fā)送
                數(shù)據(jù)庫批量保存過濾之后的list1;
            }
            ....
        }
        sendToMQ(xxx);
        list2 = .....;
        try {
             數(shù)據(jù)庫批量保存list2;
        } catch (Exception e) {
            if (e instanceof DuplicateKeyException) {
                //篩選過濾重復(fù) key 的數(shù)據(jù)
                //打標(biāo)發(fā)送
                數(shù)據(jù)庫批量保存過濾之后的list2;
            }
            ...
        }
        sendToMQ(xxx);
        return Boolean.TRUE;
    }

這個接口其實(shí)是一次性接口，用來補(bǔ)數(shù)據(jù)的，線上跑過一次后，后面應(yīng)該不會再使用。

出于保險原則，兼容上游部分?jǐn)?shù)據(jù)重復(fù)調(diào)用，所以我做了重復(fù)key的處理，剔除重復(fù)的部分，讓不重復(fù)的部分正常保存。

正常情況下不會出現(xiàn)這個場景，剛好測試環(huán)境測試來回折騰有很多重復(fù)數(shù)據(jù)（其實(shí)我這樣寫也是為了兼容測試，隨便他折騰）

這里的代碼邏輯不復(fù)雜，明面上來看，我并沒有調(diào)用別的 service ！也并不存在嵌套事務(wù)的問題，所以我思來想去也看不明白。

于是......

我出門放了個水，順帶逛了一圈，接著買了杯咖啡，遇事不決，量子力...個屁，立馬屁顛屁顛的跑回來繼續(xù)看代碼。

回來突然就看 try-catch 不爽。

但是 try 里面就是一個  mybatis-plus 的 IService，批量保存數(shù)據(jù)的操作。

難道它有什么騷操作？點(diǎn)進(jìn)去一看突然發(fā)現(xiàn)：

我丟！

喚起了我的記憶，mybatis-plus 為了保證批量保存的事務(wù)性，加了 @Transactional。

合著我確實(shí)沒想著使用嵌套事務(wù)，但是這被迫上了“賊船”??！

這本是好意，但是在我這個場景有點(diǎn)麻，它完美的復(fù)現(xiàn)了上文提到的那個錯誤使用，在有重復(fù) key 的場景確實(shí)報錯了，但是被外層 try-catch 攔住了拋錯，不過事務(wù)上已經(jīng)打了失敗的標(biāo)了！

解決辦法其實(shí)很簡單：

1. 把 saveBatch 上的 @Transactional 注解刪了，很明顯我做不到，這是 mybatisplus 的源碼。
2. 把 saveBatch 上的 @Transactional 注解上設(shè)置事務(wù)傳播機(jī)制為：REQUIRES_NEW 或 NESTED，很明顯，我也做不到，這是 mybatis-plus 的源碼。

然后我找了下，好像也沒有什么參數(shù)可以指定 saveBatch 的事務(wù)傳播機(jī)制。

所以咋辦。。。測試還在催我，沒辦法，只能不用 mybatis-plus 的 saveBatch ，自己通過 mapper 寫個批量插入了：

一波操作提交代碼重啟服務(wù)，讓測試再試試，且輕飄飄的甩一句：這不是我的bug，我被框架坑了。

咳咳，反正我不管，我的代碼沒有bug，這是程序員最后的倔強(qiáng)。

最后

所以在使用三方代碼的情況下還是需要多留個心眼點(diǎn)點(diǎn)看。

我記得以前還聽說過一個段子，就是有個人用了一個網(wǎng)上的組件，正常情況下都沒事，異常情況下，系統(tǒng)就掛了。

后面一找，那個組件在個角落嘎達(dá)寫了 System.exit。

對上面這個錯誤源碼層面分析有興趣的話 ，可以看下我之前的這篇文章群里分享的面試題，第一題就不會了？

標(biāo)題名稱：小心MybatisPlus的一個坑與面試題
URL網(wǎng)址：http://uogjgqi.cn/article/dpipcop.html