av激情亚洲男人的天堂国语,日韩欧美精品一中文字幕,无码av一区二区三区无码,国产又色又爽又刺激的a片,国产又色又爽又刺激的a片

Spring官方都推薦使用的@Transactional事務,為啥我不建議使用!

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

我們提供的服務有:成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、木蘭ssl等。為上千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務,是有科學管理、有技術(shù)的木蘭網(wǎng)站制作公司

關(guān)于事務的基礎(chǔ)知識,如什么是事務,數(shù)據(jù)庫事務以及Spring事務的ACID、隔離級別、傳播機制、行為等,就不在這篇文章中詳細介紹了。默認大家都有一定的了解。

本文,作者會先簡單介紹下什么是聲明式事務和編程式事務,再說一下為什么我不建議使用聲明式事務。

編程式事務

基于底層的API,如PlatformTransactionManager、TransactionDefinition 和 TransactionTemplate 等核心接口,開發(fā)者完全可以通過編程的方式來進行事務管理。

編程式事務方式需要是開發(fā)者在代碼中手動的管理事務的開啟、提交、回滾等操作。

 
 
 
 
  1. public void test() {
  2.       TransactionDefinition def = new DefaultTransactionDefinition();
  3.       TransactionStatus status = transactionManager.getTransaction(def);
  4.        try {
  5.          // 事務操作
  6.          // 事務提交
  7.          transactionManager.commit(status);
  8.       } catch (DataAccessException e) {
  9.          // 事務提交
  10.          transactionManager.rollback(status);
  11.          throw e;
  12.       }
  13. }

如以上代碼,開發(fā)者可以通過API自己控制事務。

聲明式事務

聲明式事務管理方法允許開發(fā)者配置的幫助下來管理事務,而不需要依賴底層API進行硬編碼。開發(fā)者可以只使用注解或基于配置的 XML 來管理事務。

 
 
 
 
  1. @Transactional
  2. public void test() {
  3.      // 事務操作  
  4. }

如上,使用@Transactional即可給test方法增加事務控制。

當然,上面的代碼只是簡化后的,想要使用事務還需要一些配置內(nèi)容。這里就不詳細闡述了。

這兩種事務,格子有各自的優(yōu)缺點,那么,各自有哪些適合的場景呢?為什么有人會拒絕使用聲明式事務呢?

聲明式事務的優(yōu)點

通過上面的例子,其實我們可以很容易的看出來,聲明式事務幫助我們節(jié)省了很多代碼,他會自動幫我們進行事務的開啟、提交以及回滾等操作,把程序員從事務管理中解放出來。

聲明式事務管理使用了 AOP 實現(xiàn)的,本質(zhì)就是在目標方法執(zhí)行前后進行攔截。 在目標方法執(zhí)行前加入或創(chuàng)建一個事務,在執(zhí)行方法執(zhí)行后,根據(jù)實際情況選擇提交或是回滾事務。

使用這種方式,對代碼沒有侵入性,方法內(nèi)只需要寫業(yè)務邏輯就可以了。

但是,聲明式事務真的有這么好么?倒也不見得。

聲明式事務的粒度問題

首先,聲明式事務有一個局限,那就是他的最小粒度要作用在方法上。

也就是說,如果想要給一部分代碼塊增加事務的話,那就需要把這個部分代碼塊單獨獨立出來作為一個方法。

但是,正是因為這個粒度問題,本人并不建議過度的使用聲明式事務。

首先,因為聲明式事務是通過注解的,有些時候還可以通過配置實現(xiàn),這就會導致一個問題,那就是這個事務有可能被開發(fā)者忽略。

事務被忽略了有什么問題呢?

首先,如果開發(fā)者沒有注意到一個方法是被事務嵌套的,那么就可能會再方法中加入一些如RPC遠程調(diào)用、消息發(fā)送、緩存更新、文件寫入等操作。

我們知道,這些操作如果被包在事務中,有兩個問題:

1、這些操作自身是無法回滾的,這就會導致數(shù)據(jù)的不一致??赡躌PC調(diào)用成功了,但是本地事務回滾了,可是PRC調(diào)用無法回滾了。

2、在事務中有遠程調(diào)用,就會拉長整個事務。那么久會導致本事務的數(shù)據(jù)庫連接一直被占用,那么如果類似操作過多,就會導致數(shù)據(jù)庫連接池耗盡。

有些時候,即使沒有在事務中進行遠程操作,但是有些人還是可能會不經(jīng)意的進行一些內(nèi)存操作,如運算?;蛘呷绻龅椒謳旆直淼那闆r,有可能不經(jīng)意間進行跨庫操作。

但是如果是編程式事務的話,業(yè)務代碼中就會清清楚楚看到什么地方開啟事務,什么地方提交,什么時候回滾。這樣有人改這段代碼的時候,就會強制他考慮要加的代碼是否應該方法事務內(nèi)。

有些人可能會說,已經(jīng)有了聲明式事務,但是寫代碼的人沒注意,這能怪誰。

話雖然是這么說,但是我們還是希望可以通過一些機制或者規(guī)范,降低這些問題發(fā)生的概率。

比如建議大家使用編程式事務,而不是聲明式事務。因為,作者工作這么多年來,發(fā)生過不止一次開發(fā)者沒注意到聲明式事務而導致的故障。

因為有些時候,聲明式事務確實不夠明顯。

聲明式事務用不對容易失效

除了事務的粒度問題,還有一個問題那就是聲明式事務雖然看上去幫我們簡化了很多代碼,但是一旦沒用對,也很容易導致事務失效。

如以下幾種場景就可能導致聲明式事務失效:

1、@Transactional 應用在非 public 修飾的方法上

2、@Transactional 注解屬性 propagation 設(shè)置錯誤

3、@Transactional 注解屬性 rollbackFor 設(shè)置錯誤

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

5、異常被catch捕獲導致@Transactional失效

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

以上幾個問題,如果使用編程式事務的話,很多都是可以避免的。

使用聲明事務失效的問題我們發(fā)生過很多次。不知道大家有沒有遇到過,我是實際遇到過的

因為Spring的事務是基于AOP實現(xiàn)的,但是在代碼中,有時候我們會有很多切面,不同的切面可能會來處理不同的事情,多個切面之間可能會有相互影響。

在之前的一個項目中,我就發(fā)現(xiàn)我們的Service層的事務全都失效了,一個SQL執(zhí)行失敗后并沒有回滾,排查下來才發(fā)現(xiàn),是因為一位同事新增了一個切面,這個切面里面做個異常的統(tǒng)一捕獲,導致事務的切面沒有捕獲到異常,導致事務無法回滾。

這樣的問題,發(fā)生過不止一次,而且不容易被發(fā)現(xiàn)。

很多人還是會說,說到底還是自己能力不行,對事務理解不透徹,用錯了能怪誰。

但是我還是那句話,我們確實無法保證所有人的能力都很高,也無法要求所有開發(fā)者都能不出錯。我們能做的就是,盡量可以通過機制或者規(guī)范,來避免或者降低這些問題發(fā)生的概率。

其實,如果大家有認真看過阿里巴巴出的那份Java開發(fā)手冊的話,其實就能發(fā)現(xiàn),其中的很多規(guī)約并不是完完全全容易被人理解,有些也比較生硬,但是其實,這些規(guī)范都是從無數(shù)個坑里爬出來的開發(fā)者們總結(jié)出來的。

關(guān)于@Transactional的用法,規(guī)約中也有提到過,只不過規(guī)約中的觀點沒有我這么鮮明:

總結(jié)

最后,相信本文的觀點很多人都并不一定認同,很多人會說:Spring官方都推薦無侵入性的聲明式事務,你有啥資格出來BB 。

說實話,剛工作的前幾年,我也熱衷于使用聲明式事務,覺得很干凈,也很"優(yōu)雅"。覺得師兄們使用編程式事務多此一舉,沒有工匠精神。

但是慢慢的,線上發(fā)生過幾次問題之后,我們復盤后發(fā)現(xiàn),很多時候你自己寫的代碼很優(yōu)雅,這完全沒問題。

但是,優(yōu)雅的同時也帶來了一些副作用,師兄們又不能批評我,因為我的用法確實沒錯…

所以,有些事,還是要痛過之后才知道。

當然,本文并不要求大家一定要徹底不使用聲明式事務,只是建議大家日后在使用事務的時候,能夠考慮到本文中提到的觀點,然后自行選擇。

【本文是專欄作者Hollis的原創(chuàng)文章,作者微信公眾號Hollis(ID:hollischuang)】


本文標題:Spring官方都推薦使用的@Transactional事務,為啥我不建議使用!
地址分享:http://uogjgqi.cn/article/djdjicc.html
掃二維碼與項目經(jīng)理溝通

我們在微信上24小時期待你的聲音

解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流