@Transactional 註解相信大家並不陌生，平時開發中很常用的一個註解，它能保證方法內多個數據庫操作要麼同時成功、要麼同時失敗。使用@Transactional註解時需要注意許多的細節，不然你會發現@Transactional總是莫名其妙的就失效了。
一、事務
事務管理在系統開發中是不可缺少的一部分，Spring提供了很好事務管理機制，主要分爲編程式事務和聲明式事務兩種。
編程式事務：是指在代碼中手動的管理事務的提交、回滾等操作，代碼侵入性比較強，如下示例：
try {
//TODO something
transactionManager.commit(status);
} catch (Exception e) {
transactionManager.rollback(status);
throw new InvoiceApplyException("異常失敗");
}
聲明式事務：基於AOP面向切面的，它將具體業務與事務處理部分解耦，代碼侵入性很低，所以在實際開發中聲明式事務用的比較多。聲明式事務也有兩種實現方式，一是基於TX和AOP的xml配置文件方式，二種就是基於@Transactional註解了。
@Transactional
@GetMapping("/test")
public String test() {
int insert = cityInfoDictMapper.insert(cityInfoDict);
}
二、@Transactional介紹
1、@Transactional註解可以作用於哪些地方
@Transactional 可以作用在接口、類、類方法。
- 作用於類：當把@Transactional 註解放在類上時，表示所有該類的public方法都配置相同的事務屬性信息。
- 作用於方法：當類配置了@Transactional，方法也配置了@Transactional，方法的事務會覆蓋類的事務配置信息。
- 作用於接口：不推薦這種使用方法，因爲一旦標註在Interface上並且配置了Spring AOP 使用CGLib動態代理，將會導致@Transactional註解失效。
2、@Transactional注有哪些屬性？
propagation屬性
propagation代表事務的傳播行爲，默認值爲 Propagation.REQUIRED，其他的屬性信息如下：
Propagation.REQUIRED：如果當前存在事務，則加入該事務，如果當前不存在事務，則創建一個新的事務。( 也就是說如果A方法和B方法都添加了註解，在默認傳播模式下，A方法內部調用B方法，會把兩個方法的事務合併爲一個事務 ）Propagation.SUPPORTS：如果當前存在事務，則加入該事務；如果當前不存在事務，則以非事務的方式繼續運行。Propagation.MANDATORY：如果當前存在事務，則加入該事務；如果當前不存在事務，則拋出異常。Propagation.REQUIRES_NEW：重新創建一個新的事務，如果當前存在事務，暫停當前的事務。( 當類A中的 a 方法用默認Propagation.REQUIRED模式，類B中的 b方法加上採用 Propagation.REQUIRES_NEW模式，然後在 a 方法中調用 b方法操作數據庫，然而 a方法拋出異常後，b方法並沒有進行回滾，因爲Propagation.REQUIRES_NEW會暫停 a方法的事務 )Propagation.NOT_SUPPORTED：以非事務的方式運行，如果當前存在事務，暫停當前的事務。Propagation.NEVER：以非事務的方式運行，如果當前存在事務，則拋出異常。Propagation.NESTED：和 Propagation.REQUIRED 效果一樣。
isolation屬性
isolation ：事務的隔離級別，默認值爲 Isolation.DEFAULT。
Isolation.DEFAULT：默認。這是一個PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別。另外四個與JDBC的隔離級別相對應。Isolation.READ_UNCOMMITTED：讀未提交。這是事務最低的隔離級別，它允許另外一個事務可以看到這個事務未提交的數據。這種隔離級別會產生髒讀，不可重複讀和幻像讀。Isolation.READ_COMMITTED：讀已提交。保證一個事務修改的數據提交後才能被另外一個事務讀取，另外一個事務不能讀取該事務未提交的數據。這種事務隔離級別可以避免髒讀出現，但是可能會出現不可重複讀和幻像讀。Isolation.REPEATABLE_READ：可重複讀。這種事務隔離級別可以防止髒讀、不可重複讀，但是可能出現幻像讀。它除了保證一個事務不能讀取另一個事務未提交的數據外，還保證了不可重複讀。Isolation.SERIALIZABLE：序列化。這是花費最高代價但是最可靠的事務隔離級別，事務被處理爲順序執行。除了防止髒讀、不可重複讀外，還避免了幻像讀。
隔離級別解決事務並行引起的問題：
timeout 屬性
timeout：事務的超時時間，默認值爲 -1。如果超過該時間限制但事務還沒有完成，則自動回滾事務。
readOnly 屬性
readOnly ：指定事務是否爲只讀事務，默認值爲 false；爲了忽略那些不需要事務的方法，比如讀取數據，可以設置 read-only 爲 true。
rollbackFor 屬性
rollbackFor ：用於指定能夠觸發事務回滾的異常類型，可以指定多個異常類型。
noRollbackFor屬性
noRollbackFor：拋出指定的異常類型，不回滾事務，也可以指定多個異常類型。
三、@Transactional失效場景
1、@Transactional 應用在非 public 修飾的方法上
如果Transactional註解應用在非public修飾的方法上，Transactional將會失效。
之所以會失效是因爲在Spring AOP 代理時，如上圖所示 TransactionInterceptor（事務攔截器）在目標方法執行前後進行攔截，DynamicAdvisedInterceptor（CglibAopProxy 的內部類）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法會間接調用 AbstractFallbackTransactionAttributeSource的 computeTransactionAttribute 方法，獲取Transactional 註解的事務配置信息。
protected TransactionAttribute computeTransactionAttribute(Method method,
Class<?> targetClass) {
// Don't allow no-public methods as required.
if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
return null;
}
}
此方法會檢查目標方法的修飾符是否爲 public，不是 public則不會獲取@Transactional 的屬性配置信息。
注意：protected、private 修飾的方法上使用 @Transactional註解，雖然事務無效，但不會有任何報錯，這是我們很容犯錯的一點。
2、@Transactional 註解屬性 propagation 設置錯誤
這種失效是由於配置錯誤，若是錯誤的配置以下三種 propagation，事務將不會發生回滾。
TransactionDefinition.PROPAGATION_SUPPORTS：如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續運行。TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事務方式運行，如果當前存在事務，則把當前事務掛起。TransactionDefinition.PROPAGATION_NEVER：以非事務方式運行，如果當前存在事務，則拋出異常。
3、@Transactional 註解屬性 rollbackFor 設置錯誤
rollbackFor 可以指定能夠觸發事務回滾的異常類型。Spring默認拋出了未檢查unchecked異常（繼承自RuntimeException的異常）或者Error纔回滾事務；其他異常不會觸發回滾事務。如果在事務中拋出其他類型的異常，但卻期望 Spring 能夠回滾事務，就需要指定rollbackFor屬性。若在目標方法中拋出的異常是 rollbackFor 指定的異常的子類，事務同樣會回滾。
4、同一個類中方法調用，導致@Transactional失效
開發中避免不了會對同一個類裏面的方法調用，比如有一個類Test，它的一個方法A，A再調用本類的方法B（不論方法B是用public還是private修飾），但方法A沒有聲明註解事務，而B方法有。則外部調用方法A之後，方法B的事務是不會起作用的。這也是經常犯錯誤的一個地方。
那爲啥會出現這種情況？其實這還是由於使用Spring AOP代理造成的，因爲只有當事務方法被當前類以外的代碼調用時，纔會由Spring生成的代理對象來管理。
//@Transactional
@GetMapping("/test")
private Integer A() throws Exception {
CityInfoDict cityInfoDict = new CityInfoDict();
cityInfoDict.setCityName("2");
/**
* B 插入字段爲 3的數據
*/
this.insertB();
/**
* A 插入字段爲 2的數據
*/
int insert = cityInfoDictMapper.insert(cityInfoDict);
return insert;
}
@Transactional()
public Integer insertB() throws Exception {
CityInfoDict cityInfoDict = new CityInfoDict();
cityInfoDict.setCityName("3");
cityInfoDict.setParentCityId(3);
return cityInfoDictMapper.insert(cityInfoDict);
}
5、異常被你的 catch“吃了”導致@Transactional失效
這種情況是最常見的一種@Transactional註解失效場景
@Transactional
private Integer A() throws Exception {
int insert = 0;
try {
CityInfoDict cityInfoDict = new CityInfoDict();
cityInfoDict.setCityName("2");
cityInfoDict.setParentCityId(2);
/**
* A 插入字段爲 2的數據
*/
insert = cityInfoDictMapper.insert(cityInfoDict);
/**
* B 插入字段爲 3的數據
*/
b.insertB();
} catch (Exception e) {
e.printStackTrace();
}
}
如果B方法內部拋了異常，而A方法此時try catch了B方法的異常，那這個事務還能正常回滾嗎？
答案：不能！
會拋出異常：
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
因爲當ServiceB中拋出了一個異常以後，ServiceB標識當前事務需要rollback。但是ServiceA中由於你手動的捕獲這個異常並進行處理，ServiceA認爲當前事務應該正常commit。此時就出現了前後不一致，也就是因爲這樣，拋出了前面的UnexpectedRollbackException異常。
spring的事務是在調用業務方法之前開始的，業務方法執行完畢之後才執行commit or rollback，事務是否執行取決於是否拋出RuntimeException。如果拋出RuntimeException 並在你的業務方法中沒有catch到的話，事務會回滾。
在業務方法中一般不需要catch異常，如果非要catch一定要拋出throw new RuntimeException()，或者註解中指定拋異常類型@Transactional(rollbackFor=Exception.class)，否則會導致事務失效，數據commit造成數據不一致，所以有些時候try catch反倒會畫蛇添足。
6、數據庫引擎不支持事務
這種情況出現的概率並不高，事務能否生效數據庫引擎是否支持事務是關鍵。常用的MySQL數據庫默認使用支持事務的innodb引擎。一旦數據庫引擎切換成不支持事務的myisam，那事務就從根本上失效了。