大廠數(shù)據(jù)庫事務(wù)實踐-事務(wù)生效就能保證正確回滾?
1 AOP實現(xiàn)事務(wù)的原理
可理解為使用 try/catch 包裹被 @Transactional 注解的方法:
- 當方法拋異常并滿足條件時,在 catch 中可設(shè)置事務(wù)回滾
- 若無異常,則直接提交事務(wù)。
剛才所說 條件 即為如下兩點:
- 只有異常傳播出了被 @Transactional注解的方法,事務(wù)才能回滾。
Spring的 TransactionAspectSupport#invokeWithinTransaction 方法即為處理事務(wù)的邏輯:只有捕獲到異常才能進行后續(xù)事務(wù)處理
- 默認當出現(xiàn) RuntimeException 或 Error,Spring才回滾事務(wù)。
查看Spring的DefaultTransactionAttribute
受檢異常一般是業(yè)務(wù)異?;蝾愃屏硪环N方法的返回值,出現(xiàn)這樣的異??赡軜I(yè)務(wù)還能完成,所以不會主動回滾
而 Error 或 RuntimeException 代表非預(yù)期結(jié)果,應(yīng)回滾
2 反面教材
2.1 注冊用戶案例
createUserError1 會拋 RuntimeException,但方法內(nèi)的 catch 捕獲了所有異常
- createUserError2,注冊用戶時還會readFile,若讀文件失敗,我們期望用戶注冊的DB操作也回滾。這里雖未捕獲異常,但因readFile拋受檢異常,createUserError2 傳播出去的也是受檢異常,事務(wù)不會回滾
- readFile
createUserError1、2 倆方法雖然可確保事務(wù)生效,但因異常處理又不當,文件操作出現(xiàn)受檢異常時,不會回滾事務(wù)。
2.2 如何修復(fù)bug呢?
通過日志來驗證是否修復(fù)成功。針對以上2種情況,修復(fù)方案分別如下。
2.2.1 修復(fù)bug1
若希望自己捕獲異常并處理,可手動設(shè)置讓當前事務(wù)處于回滾態(tài)。
查看日志,確定事務(wù)回滾了。
Transactional code has requested rollback:手動請求回滾。
2.2.2 修復(fù)bug2
在注解中聲明,期望遇到所有的Exception都回滾事務(wù)。
以此突破Spring不回滾受檢異常的默認限制。
查看日志,確認事務(wù)回滾了:
該案例的事務(wù)中不僅有DB操作還有IO操作,在IO遇到問題時期望DB事務(wù)也回滾,以確保邏輯一致性。注意別再踩坑了喲~
3 總結(jié)
由于異常處理不正確,時常導(dǎo)致事務(wù)雖然的確生效了,但發(fā)生異常時依舊沒能正確回滾。
Spring默認只對被@Transactional注解的方法出現(xiàn)RuntimeException和Error時回滾,所以若方法捕獲了異常,就需要通過手寫代碼處理事務(wù)回滾。
若希望Spring針對其他異常也可回滾,可相應(yīng)配置@Transactional注解的rollbackFor和noRollbackFor屬性覆蓋Spring的默認配置。
文轉(zhuǎn)載自微信公眾號「JavaEdge」,可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系JavaEdge公眾號。