Spring中Transactional 失效的解決方案,讓我們一起探討一下

寫在前面:2020年面試必備的Java後端進階面試題總結了一份複習指南在Github上,內容詳細,圖文並茂,有需要學習的朋友可以Star一下!
GitHub地址:https://github.com/abel-max/Java-Study-Note/tree/master

關於@Transactional註解 一般都認爲要注意以下三點:

1 .在需要事務管理的地方加@Transactional 註解。@Transactional 註解可以被應用於接口定義和接口方法、類定義和類的 public 方法上 。

2 . @Transactional 註解只能應用到 public 可見度的方法上 。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 註解,它也不會報錯, 但是這個被註解的方法將不會展示已配置的事務設置。

3 . 注意僅僅 @Transactional 註解的出現不足於開啓事務行爲,它僅僅 是一種元數據。必須在配置文件中使用配置元素,才真正開啓了事務行爲。

最近在項目中發現註解無效,經過跟蹤源代碼發現了問題,於是在網上找到相同出現此問題的人,以下爲原文,講解的很詳細:

只要避開Spring目前的AOP實現上的限制,要麼都聲明要事務,要麼分開成兩個類,要麼直接在方法裏使用編程式事務

[問題]

Spring的聲明式事務,我想就不用多介紹了吧,一句話“自從用了Spring AOP啊,事務管理真輕鬆啊,真輕鬆;事務管理代碼沒有了,腦不酸了,手不痛了,一口氣全配上了事務;輕量級,測試起來也簡單,嘿!”。不管從哪個角度看,輕量級聲明式事務都是一件解放生產力的大好事。所以,我們“一直用它”。

不過,最近的一個項目裏,卻碰到了一個事務管理上的問題:有一個服務類,其一個聲明瞭事務的方法,裏面做了三次插入SQL操作,但是在後面出錯回滾時,卻發現前面插入成功了,也是說,這個聲明瞭事務的方法,實際上並沒有真正啓動事務!怎麼回事呢?難道Spring的聲明式事務失效了?

[探幽]

其實以前也會碰到有人說,Spring的事務配置不起作用,但是根據第一反應和以往經驗,我總會告訴他,肯定是你的配置有問題啦;所以這一次,我想也不會例外,大概是把事務註解配在了接口上而不是實現方法上,或者,如果是用XML聲明方式的話,很可能是切入點的表達式沒有配對。

不過,在檢查了他們的配置後,卻發現沒有配置問題,該起事務的實現方法上,用了@Transactional事務註解聲明,XML裏也配了註解驅動<tx:annotation-driven …/>,配置很正確啊,怎麼會不起作用?

我很納悶,於是往下問:

問1:其他方法有這種情況麼?

答1:沒有。

問2:這個方法有什麼特別的麼(以下簡稱方法B)?

答2:就是調後臺插了三條記錄啊,沒啥特別的。

問3:這個方法是從Web層直接調用的吧?

答3:不是,是這個Service類(以下簡稱ServiceA)的另外一個方法調過來的(以下簡稱方法A)。

問4:哦,那個調用它的方法配了事務麼(問題可能在這了)?

答4:沒有。

問5:那WEB層的Action(用的是Struts2),調用的是沒有聲明事務的方法A,方法A再調用聲明瞭事務的方法B?

答5:對的。

問6:你直接在方法A上加上事務聲明看看

答6:好。。。

看來可能找到問題所在了,於是把@Transactional也加在方法A上,啓動項目測試,結果是:事務正常生效,方法A和方法B都在一個事務裏了。

好了,現在總結一下現象:

1、ServiceA類爲Web層的Action服務

2、Action調用了ServiceA的方法A,而方法A沒有聲明事務(原因是方法A本身比較耗時而又不需要事務)

3、ServiceA的方法A調用了自己所在class的方法B,而方法B聲明瞭事務,但是方法B的事務聲明在這種情況失效了。

4、如果在方法A上也聲明事務,則在Action調用方法A時,事務生效,而方法B則自動參與了這個事務。

我讓他先把A也加上事務聲明,決定回來自己再測一下。

這個問題,表面上是事務聲明失效的問題,實質上很可能是Spring的AOP機制實現角度的問題。

我想到很久以前研究Spring的AOP實現時發現的一個現象:對於以Cglib方式增強的AOP目標類,會創建兩個對象,一個事Bean實例本身,一個是Cglib增強代理對象,而不僅僅是隻有後者。我曾經疑惑過這一點,但當時沒有再仔細探究下去。

我們知道,Spring的AOP實現方式有兩種:
1、Java代理方式;
2、Cglib動態增強方式,這兩種方式在Spring中是可以無縫自由切換的。

Java代理方式的優點是不依賴第三方jar包,缺點是不能代理類,只能代理接口。

Spring通過AopProxy接口,抽象了這兩種實現,實現了一致的AOP方式:
image

現在看來,這種抽象同樣帶了一個缺陷,那就是抹殺了Cglib能夠直接創建普通類的增強子類的能力,Spring相當於把Cglib動態生成的子類,當普通的代理類了,這也是爲什麼會創建兩個對象的原因。下圖顯示了Spring的AOP代理類的實際調用過程:

image

因此,從上面的分析可以看出,methodB沒有被AopProxy通知到,

導致最終結果是: 被Spring的AOP增強的類,在同一個類的內部方法調用時,其被調用方法上的增強通知將不起作用。

而這種結果,會造成什麼影響呢:

1:內部調用時,被調用方法的事務聲明將不起作用

2:換句話說,你在某個方法上聲明它需要事務的時候,如果這個類還有其他開發者,你將 不能保證這個方法真的會在事務環境中

3:再換句話說,Spring的事務傳播策略在內部方法調用時將不起作用。

不管你希望某個方法需要單獨事務,是RequiresNew,還是要嵌套事務,要Nested,等等,統統不起作用。

4:不僅僅是事務通知,所有你自己利用Spring實現的AOP通知,都會受到同樣限制。。。。

[解難]

問題的原因已經找到,其實,我理想中的AOP實現,應該是下面這樣:

image

只要一個Cglib增強對象就好,對於Java代理方式,我的選擇是毫不猶豫的拋棄。

至於前面的事務問題,只要避開Spring目前的AOP實現上的限制,要麼都聲明要事務,要麼分開成兩個類,要麼直接在方法裏使用編程式事務,那麼一切OK。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章