疑問(wèn),確實(shí)像往常一樣在service上添加了注解
@Transactional
,為什么查詢數(shù)據(jù)庫(kù)時(shí)還是發(fā)現(xiàn)有數(shù)據(jù)不一致的情況,想想肯定是事務(wù)沒(méi)起作用,出現(xiàn)異常的時(shí)候數(shù)據(jù)沒(méi)有回滾。于是就對(duì)相關(guān)代碼進(jìn)行了一番測(cè)試,結(jié)果發(fā)現(xiàn)一下踩進(jìn)了兩個(gè)坑,確實(shí)是事務(wù)未回滾導(dǎo)致的數(shù)據(jù)不一致。下面總結(jié)一下經(jīng)驗(yàn)教訓(xùn):
Spring事務(wù)的管理操作方法
下面先總結(jié)一下Spring的事務(wù)管理方式,spring支持兩種事務(wù)管理的操作方式,編程式的和聲明式的(xml或者注解)。
- 編程式的事務(wù)管理
- 實(shí)際應(yīng)用中很少使用
- 通過(guò)使用
TransactionTemplate
手動(dòng)管理事務(wù) - 聲明式的事務(wù)管理
- 開(kāi)發(fā)中推薦使用(代碼侵入最少)
- Spring的聲明式事務(wù)是通過(guò)AOP實(shí)現(xiàn)的
主要掌握聲明式的事務(wù)管理。
spring事務(wù)不回滾的兩個(gè)原因
總結(jié)一下導(dǎo)致事務(wù)不回滾的兩個(gè)原因,一是Service類(lèi)內(nèi)部方法調(diào)用,二是try...catch異常。
1. Service類(lèi)內(nèi)部方法調(diào)用
大概就是 Service 中有一個(gè)方法 A,會(huì)內(nèi)部調(diào)用方法 B, 方法 A 沒(méi)有事務(wù)管理,方法 B 采用了聲明式事務(wù),通過(guò)在方法上聲明 Transactional 的注解來(lái)做事務(wù)管理。示例代碼如下:
@Service
public class RabbitServiceImpl implements RabbitService {
@Autowired
private RabbitDao rabbitDao;
@Autowired
private TortoiseDao tortoiseDao;
@Override
public Rabbit methodA(String name){
return methodB(name);
}
@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED)
public boolean methodB(String name){
rabbitDao.insertRabbit(name);
tortoiseDao.insertTortoise(name);
return true;
}
}
單元測(cè)試代碼如下:
public class RabbitServiceImplTest {
@Autowired
private RabbitService rabbitService;
// 事務(wù)未開(kāi)啟
@Test
public void testA(){
rabbitService.methodA("rabbit");
}
// 事務(wù)開(kāi)啟
@Test
public void testB(){
rabbitService.methodB("rabbit");
}
}
從上一節(jié)中可以看到,聲明式事務(wù)是通通過(guò)AOP動(dòng)態(tài)代理實(shí)現(xiàn)的,這樣會(huì)產(chǎn)生一個(gè)代理類(lèi)來(lái)做事務(wù)管理,而目標(biāo)類(lèi)(service)本身是不能感知代理類(lèi)的存在的。
對(duì)于加了@Transactional注解的方法來(lái)說(shuō),在調(diào)用代理類(lèi)的方法時(shí),會(huì)先通過(guò)攔截器TransactionInterceptor開(kāi)啟事務(wù),然后在調(diào)用目標(biāo)類(lèi)的方法,最后在調(diào)用結(jié)束后,TransactionInterceptor 會(huì)提交或回滾事務(wù),大致流程如下圖:
總結(jié),在方法 A 中調(diào)用方法 B,實(shí)際上是通過(guò)“this”的引用,也就是直接調(diào)用了目標(biāo)類(lèi)的方法,而非通過(guò) Spring 上下文獲得的代理類(lèi),所以事務(wù)是不會(huì)開(kāi)啟的。
2. try...catch異常
在一段業(yè)務(wù)邏輯中對(duì)數(shù)據(jù)庫(kù)異常進(jìn)行了處理,使用了try...catch子句捕獲異常并throw了一個(gè)自定義異常,這種情況導(dǎo)致了事務(wù)未回滾,示例代碼如下:
@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED)
public boolean methodB(String name) throws BizException {
try {
rabbitDao.insertRabbit(name);
tortoiseDao.insertTortoise(name);
} catch (Exception e) {
throw new BizException(ReturnCode.EXCEPTION.code, ReturnCode.EXCEPTION.msg);
}
return true;
}
BizException的定義如下:
public class BizException extends Exception {
// 自定義異常
}
上面代碼中的聲明式事務(wù)在出現(xiàn)異常的時(shí)候,事務(wù)是不會(huì)回滾的。在代碼中我雖然捕獲了異常,但是同時(shí)我也拋出了異常,為什么事務(wù)未回滾呢?猜測(cè)是異常類(lèi)型不對(duì),于是開(kāi)始查詢?cè)颍戳?a target="_blank" rel="nofollow">Spring的官方文檔,找到了答案。下面是翻譯自Spring官網(wǎng)。
17.5.3 聲明式事務(wù)的回滾
上一節(jié)中介紹了如何設(shè)置開(kāi)啟Spring事務(wù),一般在你的應(yīng)用的Service層代碼中設(shè)置,這一節(jié)將介紹在簡(jiǎn)單流行的聲明式事務(wù)中如何控制事務(wù)回滾。
在Spring FrameWork 的事務(wù)框架中推薦的事務(wù)回滾方法是,在當(dāng)前執(zhí)行的事務(wù)上下文中拋出一個(gè)異常。如果異常未被處理,當(dāng)拋出異常調(diào)用堆棧的時(shí)候,Spring FrameWork 的事務(wù)框架代碼將捕獲任何未處理的異常,然后并決定是否將此事務(wù)標(biāo)記為回滾。
- 在默認(rèn)配置中,Spring FrameWork 的事務(wù)框架代碼只會(huì)將出現(xiàn)
runtime, unchecked
異常的事務(wù)標(biāo)記為回滾;也就是說(shuō)事務(wù)中拋出的異常時(shí)RuntimeException或者是其子類(lèi),這樣事務(wù)才會(huì)回滾(默認(rèn)情況下Error也會(huì)導(dǎo)致事務(wù)回滾)。在默認(rèn)配置的情況下,所有的 checked 異常都不會(huì)引起事務(wù)回滾。
注:Unchecked Exception包括Error與RuntimeException. RuntimeException的所有子類(lèi)也都屬于此類(lèi)。另一類(lèi)就是checked Exception。
- 你可以精確的配置異常類(lèi)型,指定此異常類(lèi)事務(wù)回滾,包括 checked 異常。下面的xml代碼片段展示了如何配置checked異常引起事務(wù)回滾,應(yīng)用自定義異常類(lèi)型:
<tx:advice id="txAdvice" transaction-manager="txManager">
<tx:attributes>
<tx:method name="get*" read-only="true" rollback-for="NoProductInStockException"/>
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
與其有同等作用的注解形式如下:
@Transactional(rollbackForClassName={"NoProductInStockException"})
或者
@Transactional(rollbackFor={NoProductInStockException.class})
- 在你遇到異常不想回滾事務(wù)的時(shí)候,同樣的你也可指定不回滾的規(guī)則,下面的一個(gè)例子告訴你,即使遇到未處理的
InstrumentNotFoundException
異常時(shí),Spring FrameWork 的事務(wù)框架同樣會(huì)提交事務(wù),而不回滾。
<tx:advice id="txAdvice">
<tx:attributes>
<tx:method name="updateStock" no-rollback-for="InstrumentNotFoundException"/>
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
與其有同樣作用的注解形式如下:
@Transactional(noRollbackForClassName={"InstrumentNotFoundException"})
或者
@Transactional(noRollbackFor={InstrumentNotFoundException.class})
- 還有更靈活的回滾規(guī)則配置方法,同時(shí)指定什么異常回滾,什么異常不回滾。當(dāng)Spring FrameWork 的事務(wù)框架捕獲到一個(gè)異常的時(shí)候,會(huì)去匹配配置的回滾規(guī)則來(lái)決定是否標(biāo)記回滾事務(wù),使用匹配度最強(qiáng)的規(guī)則結(jié)果。因此,下面的配置例子表達(dá)的意思是,除了異常
InstrumentNotFoundException
之外的任何異常都會(huì)導(dǎo)致事務(wù)回滾。
<tx:advice id="txAdvice">
<tx:attributes>
<tx:method name="*" rollback-for="Throwable" no-rollback-for="InstrumentNotFoundException"/>
</tx:attributes>
</tx:advice>
- 你也可以通過(guò)編程式的方式回滾一個(gè)事務(wù),盡管方法非常簡(jiǎn)單,但是也有非常強(qiáng)的代碼侵入性,使你的業(yè)務(wù)代碼和Spring FrameWork 的事務(wù)框架代碼緊密的綁定在一起,示例代碼如下:
public void resolvePosition() {
try {
// some business logic...
} catch (NoProductInStockException ex) {
// trigger rollback programmatically
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}
}
如果可能的話,強(qiáng)烈推薦您使用聲明式事務(wù)方式回滾事務(wù),對(duì)于編程式事務(wù),如果你強(qiáng)烈需要它,也是可以使用的,but its usage flies in the face of achieving a clean POJO-based architecture.(沒(méi)懂...)
看完官方文檔這節(jié)內(nèi)容找到了問(wèn)題的答案,原來(lái)是因?yàn)槲覀冏远x的異常不是 RuntimeException
。我的解決辦法是,在注解@Transactional
中添加 rollbackFor={BizException.class}
。可能你會(huì)問(wèn)我為什么不將自定義異常修改為繼承RuntimeException,因?yàn)槲倚枰狟izException是一個(gè)checked 異常。
結(jié)束語(yǔ):終于將spring事務(wù)中的異常回滾機(jī)制搞明白啦,歡迎讀者在評(píng)論區(qū)添加其他導(dǎo)致spring事務(wù)不回滾的原因。