@Transactional是我們在用Spring時(shí)候幾乎逃不掉的一個(gè)注解，該注解主要用來聲明事務(wù)。它的實(shí)現(xiàn)原理是通過Spring AOP在注解修飾方法的前后織入事務(wù)管理的實(shí)現(xiàn)語句，所以開發(fā)者只需要通過一個(gè)注解就能代替一系列繁瑣的事務(wù)開始、事務(wù)關(guān)閉等重復(fù)性的編碼任務(wù)。

編碼方式確實(shí)簡單了，但也因?yàn)殡[藏了直觀的實(shí)現(xiàn)邏輯，一些錯(cuò)誤的編碼方法可能會(huì)讓@Transactional注解失效，達(dá)不到事務(wù)的作用。最直接的表現(xiàn)就是：方法執(zhí)行過程中拋出了異常，但事務(wù)沒有回滾，最終導(dǎo)致了臟數(shù)據(jù)的產(chǎn)生。

之前我在博客上也寫過一篇有趣的討論我來出個(gè)題：這個(gè)事務(wù)會(huì)不會(huì)回滾？，當(dāng)時(shí)很多人都給出了標(biāo)準(zhǔn)的錯(cuò)誤答案，如果沒看過的小伙伴不妨進(jìn)去挑戰(zhàn)一下？

雖然之前討論了一些特殊情況，但還是一直有小伙伴會(huì)郵件、微信群里問一些關(guān)于事務(wù)失效的問題。主要還是@Transactional聲明事務(wù)失效的情況真的是多種多樣！所以，今天寫一篇總結(jié)一下，如果下次再碰到，那就打開這片文章，一個(gè)個(gè)順下來看，是不是哪里寫錯(cuò)了。當(dāng)然可能這里還會(huì)有遺漏，所以如果你有其他錯(cuò)誤案例，也可以告訴我，我會(huì)持續(xù)整理到這篇文章里。

1.在同一個(gè)類中調(diào)用

錯(cuò)誤案例：

class A {
? ??
? ? public void methodA() {
? ? ? ? methodB();
? ? ? ??
? ? ? ? // 其他操作
? ? }

? ? @Transactional
? ? public void methodB() {
? ? ? ? // 寫數(shù)據(jù)庫操作
? ? }
? ??
}

這類錯(cuò)誤適用于所有基于Spring AOP實(shí)現(xiàn)的注解，比如：[《使用@Async實(shí)現(xiàn)異步調(diào)用》]中提到的@Async注解，[《使用@Scheduled實(shí)現(xiàn)定時(shí)任務(wù)》]中提到的@Scheduled注解，還有[Spring緩存注解的使用解]中提到的@Cacheable注解等。

解決這個(gè)問題的方法比較簡單，還是合理規(guī)劃好層次關(guān)系即可，比如這樣：

@Service
@AllArgsConstructor
public class A {
? ??
? ? private B b;
? ??
? ? public void methodA() {
? ? ? ? b.methodB();
? ? ? ? // 其他操作
? ? }
}

@Service
public class B {

? ? @Transactional
? ? public void methodB() {
? ? ? ? // 寫數(shù)據(jù)庫操作
? ? }
? ??
}

注意：這里A類用了構(gòu)造器注入B的實(shí)現(xiàn)（為什么沒用@Autowrire，可以看看前幾天分享的這篇[什么時(shí)候不要用@Autowired注入]，構(gòu)造函數(shù)用Lombok的@AllArgsConstructor生成（這個(gè)不熟悉的話可以看看之前這篇[Lombok：讓JAVA代碼更優(yōu)雅]。

2. @Transactional修飾方法不是public

錯(cuò)誤案例：

public class TransactionalMistake {
? ??
? ? @Transactional
? ? private void method() {
? ? ? ? // 寫數(shù)據(jù)庫操作
? ? }
? ??
}

這也是基于Spring AOP實(shí)現(xiàn)的注解所要滿足的要求。這個(gè)最簡單，很好理解，也很直觀，就不詳細(xì)展開了。直接把方法訪問類型改成public即可。

3. 不同的數(shù)據(jù)源

錯(cuò)誤案例：

public class TransactionalMistake {

? ? @Transactional
? ? public void createOrder(Order order) {
? ? ? ? orderRepo1.save(order);
? ? ? ? orderRepo2.save(order);
? ? }

}

有的時(shí)候，我們一個(gè)操作可能會(huì)同時(shí)寫多個(gè)數(shù)據(jù)源，比如上面這個(gè)例子里的orderRepo1和orderRepo2是連接的兩個(gè)不同數(shù)據(jù)源。默認(rèn)情況下，這種跨數(shù)據(jù)源的事務(wù)是不會(huì)成功的。

如果要在多個(gè)數(shù)據(jù)源之間實(shí)現(xiàn)事務(wù)，那么可以引入JTA，具體如何做的話可以看看之前的這篇分享《使用JTA實(shí)現(xiàn)多數(shù)據(jù)源的事務(wù)管理》

4. 回滾異常配置不正確

默認(rèn)情況下，僅對RuntimeException和Error進(jìn)行回滾。如果不是的它們及它們的子孫異常的話，就不會(huì)回滾。

所以，在自定義異常的時(shí)候，要做好適當(dāng)?shù)囊?guī)劃，如果要影響事務(wù)回滾，可以定義為RuntimeException的子類；如果不是RuntimeException，但也希望觸發(fā)回滾，那么可以使用rollbackFor屬性來指定要回滾的異常。

public class TransactionalMistake {

? ? @Transactional(rollbackFor = XXXException.class)
? ? public void method() throws XXXException {

? ? }

}

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

這個(gè)來源于一個(gè)讀者反饋的例子，代碼跟我的案例一摸一樣，我這邊是好的，但他就是不回滾。

后來排查出來是因?yàn)槁┝艘粋€(gè)關(guān)鍵屬性的配置：

spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect

這里的spring.jpa.database-platform配置主要用來設(shè)置hibernate使用的方言。這里特地采用了MySQL5InnoDBDialect，主要為了保障在使用Spring Data JPA時(shí)候，Hibernate自動(dòng)創(chuàng)建表的時(shí)候使用InnoDB存儲引擎，不然就會(huì)以默認(rèn)存儲引擎MyISAM來建表，而MyISAM存儲引擎是沒有事務(wù)的。

如果你的事務(wù)沒有生效，那么可以看看創(chuàng)建的表，是不是使用了MyISAM存儲引擎，如果是的話，那就是這個(gè)原因了！

小結(jié)

到此這篇關(guān)于java使用@Transactional時(shí)常犯的N種錯(cuò)誤的文章就介紹到這了,更多相關(guān)@Transactional 錯(cuò)誤內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！