1 AOP實(shí)現(xiàn)事務(wù)的原理

可理解為使用 try/catch 包裹被 @Transactional 注解的方法：

• 當(dāng)方法拋異常并滿足條件時(shí)，在 catch 中可設(shè)置事務(wù)回滾
• 若無異常，則直接提交事務(wù)。

剛才所說 條件 即為如下兩點(diǎn)：

• 只有異常傳播出了被 @Transactional注解的方法，事務(wù)才能回滾。

Spring的 TransactionAspectSupport#invokeWithinTransaction 方法即為處理事務(wù)的邏輯：只有捕獲到異常才能進(jìn)行后續(xù)事務(wù)處理

• 默認(rèn)當(dāng)出現(xiàn) RuntimeException 或 Error，Spring才回滾事務(wù)。

查看Spring的DefaultTransactionAttribute

受檢異常一般是業(yè)務(wù)異?；蝾愃屏硪环N方法的返回值，出現(xiàn)這樣的異常可能業(yè)務(wù)還能完成，所以不會(huì)主動(dòng)回滾

而 Error 或 RuntimeException 代表非預(yù)期結(jié)果，應(yīng)回滾

2 反面教材

2.1 注冊(cè)用戶案例[[352798]]

• createUserError1 會(huì)拋 RuntimeException，但方法內(nèi)的 catch 捕獲了所有異常

• createUserError2，注冊(cè)用戶時(shí)還會(huì)readFile，若讀文件失敗，我們期望用戶注冊(cè)的DB操作也回滾。這里雖未捕獲異常，但因readFile拋受檢異常，createUserError2 傳播出去的也是受檢異常，事務(wù)不會(huì)回滾

• readFile

createUserError1、2 倆方法雖然可確保事務(wù)生效，但因異常處理又不當(dāng)，文件操作出現(xiàn)受檢異常時(shí)，不會(huì)回滾事務(wù)。

2.2 如何修復(fù)bug呢? 

通過日志來驗(yàn)證是否修復(fù)成功。針對(duì)以上2種情況，修復(fù)方案分別如下。

2.2.1 修復(fù)bug1

若希望自己捕獲異常并處理，可手動(dòng)設(shè)置讓當(dāng)前事務(wù)處于回滾態(tài)。

查看日志，確定事務(wù)回滾了。

2.2.2 修復(fù)bug2

在注解中聲明，期望遇到所有的Exception都回滾事務(wù)。

以此突破Spring不回滾受檢異常的默認(rèn)限制。

查看日志，確認(rèn)事務(wù)回滾了：

該案例的事務(wù)中不僅有DB操作還有IO操作，在IO遇到問題時(shí)期望DB事務(wù)也回滾，以確保邏輯一致性。注意別再踩坑了喲~

3 總結(jié)

由于異常處理不正確，時(shí)常導(dǎo)致事務(wù)雖然的確生效了，但發(fā)生異常時(shí)依舊沒能正確回滾。

Spring默認(rèn)只對(duì)被@Transactional注解的方法出現(xiàn)RuntimeException和Error時(shí)回滾，所以若方法捕獲了異常，就需要通過手寫代碼處理事務(wù)回滾。

若希望Spring針對(duì)其他異常也可回滾，可相應(yīng)配置@Transactional注解的rollbackFor和noRollbackFor屬性覆蓋Spring的默認(rèn)配置。