一、Spring事務(wù)管理的兩種方式

事務(wù)管理在系統(tǒng)開發(fā)中是不可缺少的一部分，Spring提供了很好事務(wù)管理機制，主要分為編程式事務(wù)和聲明式事務(wù)兩種。

編程式事務(wù)：是指在代碼中手動的管理事務(wù)的提交、回滾等操作，代碼侵入性比較強，如下示例：

聲明式事務(wù)：是建立在AOP之上的，其本質(zhì)是對方法前后進(jìn)行攔截，然后在目標(biāo)方法開始之前創(chuàng)建或者加入一個事務(wù)，在執(zhí)行完目標(biāo)方法之后根據(jù)執(zhí)行情況提交或者回滾事務(wù)。

最大的優(yōu)點就是不需要通過編程的方式管理事務(wù)，這樣就不需要在業(yè)務(wù)邏輯代碼中摻雜事務(wù)管理的代碼，只需在配置文件中做相關(guān)的事務(wù)規(guī)則聲明(或通過基于@Transactional注解的方式)，便可以將事務(wù)規(guī)則應(yīng)用到業(yè)務(wù)邏輯中。

顯然聲明式事務(wù)管理要優(yōu)于編程式事務(wù)管理，這正是spring倡導(dǎo)的非侵入式的開發(fā)方式。聲明式事務(wù)管理使業(yè)務(wù)代碼不受污染，一個普通的POJO對象，只要加上注解就可以獲得完全的事務(wù)支持。

和編程式事務(wù)相比，聲明式事務(wù)唯一不足地方是，它的最細(xì)粒度只能作用到方法級別，無法做到像編程式事務(wù)那樣可以作用到代碼塊級別。

聲明式事務(wù)也有兩種實現(xiàn)方式，

基于TX和AOP的xml配置文件方式
基于@Transactional注解

?

?

二、@Transactional注解介紹

1、@Transactional注解可以作用于哪些地方？

@Transactional 可以作用在接口、類、類方法。

作用于類：當(dāng)把@Transactional 注解放在類上時，表示所有該類的public方法都配置相同的事務(wù)屬性信息。

作用于方法：當(dāng)類配置了@Transactional，方法也配置了@Transactional，方法的事務(wù)會覆蓋類的事務(wù)配置信息。

作用于接口：不推薦這種使用方法，因為一旦標(biāo)注在Interface上并且配置了Spring AOP 使用CGLib動態(tài)代理，將會導(dǎo)致@Transactional注解失效。

2、@Transactional注解有哪些屬性？

propagation屬性

事務(wù)的傳播行為，默認(rèn)值為 Propagation.REQUIRED，屬性信息如下：

Propagation.REQUIRED：如果當(dāng)前存在事務(wù)，則加入該事務(wù)，如果當(dāng)前不存在事務(wù)，則創(chuàng)建一個新的事務(wù)。( 也就是說如果A方法和B方法都添加了注解，在默認(rèn)傳播模式下，A方法內(nèi)部調(diào)用B方法，會把兩個方法的事務(wù)合并為一個事務(wù) ）

Propagation.SUPPORTS：如果當(dāng)前存在事務(wù)，則加入該事務(wù)；如果當(dāng)前不存在事務(wù)，則以非事務(wù)的方式繼續(xù)運行。

Propagation.MANDATORY：如果當(dāng)前存在事務(wù)，則加入該事務(wù)；如果當(dāng)前不存在事務(wù)，則拋出異常。

Propagation.REQUIRES_NEW：重新創(chuàng)建一個新的事務(wù)，如果當(dāng)前存在事務(wù)，暫停當(dāng)前的事務(wù)。( 當(dāng)類A中的 a 方法用默認(rèn)Propagation.REQUIRED模式，類B中的 b方法加上采用 Propagation.REQUIRES_NEW模式，然后在 a 方法中調(diào)用 b方法操作數(shù)據(jù)庫，然而 a方法拋出異常后，b方法并沒有進(jìn)行回滾，因為Propagation.REQUIRES_NEW會暫停 a方法的事務(wù) )

Propagation.NOT_SUPPORTED：以非事務(wù)的方式運行，如果當(dāng)前存在事務(wù)，暫停當(dāng)前的事務(wù)。

Propagation.NEVER：以非事務(wù)的方式運行，如果當(dāng)前存在事務(wù)，則拋出異常。

Propagation.NESTED：和 Propagation.REQUIRED 效果一樣。

isolation 屬性

事務(wù)的隔離級別，默認(rèn)值為 Isolation.DEFAULT。

Isolation.DEFAULT：使用底層數(shù)據(jù)庫默認(rèn)的隔離級別。

Isolation.READ_UNCOMMITTED ：未提交讀

Isolation.READ_COMMITTED ：已提交讀

Isolation.REPEATABLE_READ ：可重復(fù)讀

Isolation.SERIALIZABLE ：串型化

timeout 屬性

事務(wù)的超時時間，默認(rèn)值為 -1。如果超過該時間限制但事務(wù)還沒有完成，則自動回滾事務(wù)。

readOnly 屬性

指定事務(wù)是否為只讀事務(wù)，默認(rèn)值為 false；為了忽略那些不需要事務(wù)的方法，比如讀取數(shù)據(jù)，可以設(shè)置 read-only 為 true。

rollbackFor 屬性

用于指定能夠觸發(fā)事務(wù)回滾的異常類型，可以指定多個異常類型。

noRollbackFor屬性

拋出指定的異常類型，不回滾事務(wù)，也可以指定多個異常類型。

?

三、@Transactional的6種失效場景

1、@Transactional 應(yīng)用在非 public 修飾的方法上
如果Transactional注解應(yīng)用在非 public 修飾的方法上，Transactional將會失效。

是因為在Spring AOP 代理時，TransactionInterceptor （事務(wù)攔截器）在目標(biāo)方法執(zhí)行前后進(jìn)行攔截，DynamicAdvisedInterceptor（CglibAopProxy 的內(nèi)部類）的intercept方法 或 JdkDynamicAopProxy的invoke方法會間接調(diào)用AbstractFallbackTransactionAttributeSource的?computeTransactionAttribute方法，獲取Transactional 注解的事務(wù)配置信息。

此方法會檢查目標(biāo)方法的修飾符是否為 public，不是 public則不會獲取@Transactional 的屬性配置信息。

注意：protected、private 修飾的方法上使用 @Transactional 注解，雖然事務(wù)無效，但不會有任何報錯，這是我們很容易犯錯的一點。

2、@Transactional 注解屬性 propagation 設(shè)置錯誤
這種失效是由于配置錯誤，若是錯誤的配置以下三種 propagation，事務(wù)將不會發(fā)生回滾。

TransactionDefinition.PROPAGATION_SUPPORTS：如果當(dāng)前存在事務(wù)，則加入該事務(wù)；如果當(dāng)前沒有事務(wù)，則以非事務(wù)的方式繼續(xù)運行。

TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事務(wù)方式運行，如果當(dāng)前存在事務(wù)，則把當(dāng)前事務(wù)掛起。

TransactionDefinition.PROPAGATION_NEVER：以非事務(wù)方式運行，如果當(dāng)前存在事務(wù)，則拋出異常。

3、@Transactional 注解屬性 rollbackFor 設(shè)置錯誤
rollbackFor 可以指定能夠觸發(fā)事務(wù)回滾的異常類型。Spring默認(rèn)拋出了未檢查unchecked異常（繼承自 RuntimeException的異常）或者 Error才回滾事務(wù)，其他異常不會觸發(fā)回滾事務(wù)。

若在目標(biāo)方法中拋出的異常是 rollbackFor 指定的異常的子類，事務(wù)同樣會回滾。

4、同一個類中方法調(diào)用，導(dǎo)致@Transactional失效

開發(fā)中避免不了會對同一個類里面的方法調(diào)用，比如有一個類Test，它的一個方法A，A再調(diào)用本類的方法B（不論方法B是用public還是private修飾），但方法A沒有聲明注解事務(wù)，而B方法有。則外部調(diào)用方法A之后，方法B的事務(wù)是不會起作用的。這也是經(jīng)常犯錯誤的一個地方。

那為啥會出現(xiàn)這種情況？其實這還是由于使用Spring AOP代理造成的，因為只有當(dāng)事務(wù)方法被當(dāng)前類以外的代碼調(diào)用時，才會由Spring生成的代理對象來管理。

?

5、異常被catch捕獲導(dǎo)致@Transactional失效

這種情況是最常見的一種@Transactional注解失效場景

如果B方法內(nèi)部拋了異常，而A方法此時try catch了B方法的異常，那這個事務(wù)就不能正常回滾了，會拋出異常：

因為當(dāng)ServiceB中拋出了一個異常以后，ServiceB標(biāo)識當(dāng)前事務(wù)需要rollback。但是ServiceA中由于你手動的捕獲這個異常并進(jìn)行處理，ServiceA認(rèn)為當(dāng)前事務(wù)應(yīng)該正常commit。此時就出現(xiàn)了前后不一致，也就是因為這樣，拋出了前面的UnexpectedRollbackException異常。

spring的事務(wù)是在調(diào)用業(yè)務(wù)方法之前開始的，業(yè)務(wù)方法執(zhí)行完畢之后才執(zhí)行commit or rollback，事務(wù)是否執(zhí)行取決于是否拋出runtime異常。如果拋出runtime exception 并在你的業(yè)務(wù)方法中沒有catch到的話，事務(wù)會回滾。

在業(yè)務(wù)方法中一般不需要catch異常，如果非要catch一定要拋出throw new RuntimeException()，或者注解中指定拋異常類型@Transactional(rollbackFor=Exception.class)，否則會導(dǎo)致事務(wù)失效，數(shù)據(jù)commit造成數(shù)據(jù)不一致，所以有些時候try catch反倒會畫蛇添足。

6、數(shù)據(jù)庫引擎不支持事務(wù)

這種情況出現(xiàn)的概率并不高，事務(wù)能否生效數(shù)據(jù)庫引擎是否支持事務(wù)是關(guān)鍵。常用的MySQL數(shù)據(jù)庫默認(rèn)使用支持事務(wù)的innodb引擎，一旦數(shù)據(jù)庫引擎切換成不支持事務(wù)的myisam，那事務(wù)就從根本上失效了

?

?

?

總結(jié)

以上是生活随笔為你收集整理的面试一口气说出Spring的声明式事务@Transactional注解的6种失效场景的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。