spring的@Transactional註解詳細用法

概述

事務管理對於企業應用來講是相當重要的，即便出現異常狀況，它也能夠保證數據的一致性。
Spring Framework對事務管理提供了一致的抽象，其特色以下：

• 爲不一樣的事務API提供一致的編程模型，好比JTA(Java Transaction API), JDBC, Hibernate, JPA(Java Persistence API和JDO(Java Data Objects)
• 支持聲明式事務管理，特別是基於註解的聲明式事務管理，簡單易用
• 提供比其餘事務API如JTA更簡單的編程式事務管理API
• 與spring數據訪問抽象的完美集成

事務管理方式

spring支持編程式事務管理和聲明式事務管理兩種方式。

編程式事務管理使用TransactionTemplate或者直接使用底層的PlatformTransactionManager。對於編程式事務管理，spring推薦使用TransactionTemplate。

聲明式事務管理創建在AOP之上的。其本質是對方法先後進行攔截，而後在目標方法開始以前建立或者加入一個事務，在執行完目標方法以後根據執行狀況提交或者回滾事務。聲明式事務最大的優勢就是不須要經過編程的方式管理事務，這樣就不須要在業務邏輯代碼中摻瑣事務管理的代碼，只需在配置文件中作相關的事務規則聲明(或經過基於@Transactional註解的方式)，即可以將事務規則應用到業務邏輯中。

顯然聲明式事務管理要優於編程式事務管理，這正是spring倡導的非侵入式的開發方式。聲明式事務管理使業務代碼不受污染，一個普通的POJO對象，只要加上註解就能夠得到徹底的事務支持。和編程式事務相比，聲明式事務惟一不足地方是，後者的最細粒度只能做用到方法級別，沒法作到像編程式事務那樣能夠做用到代碼塊級別。可是即使有這樣的需求，也存在不少變通的方法，好比，能夠將須要進行事務管理的代碼塊獨立爲方法等等。

聲明式事務管理也有兩種經常使用的方式，一種是基於tx和aop名字空間的xml配置文件，另外一種就是基於@Transactional註解。顯然基於註解的方式更簡單易用，更清爽。

自動提交(AutoCommit)與鏈接關閉時的是否自動提交

自動提交

默認狀況下，數據庫處於自動提交模式。每一條語句處於一個單獨的事務中，在這條語句執行完畢時，若是執行成功則隱式的提交事務，若是
執行失敗則隱式的回滾事務。

對於正常的事務管理，是一組相關的操做處於一個事務之中，所以必須關閉數據庫的自動提交模式。不過，這個咱們不用擔憂，spring會將底層鏈接的自動提交特性設置爲false。
org/springframework/jdbc/datasource/DataSourceTransactionManager.java

 1 // switch to manual commit if necessary. this is very expensive in some jdbc drivers,
 2 // so we don't want to do it unnecessarily (for example if we've explicitly
 3 // configured the connection pool to set it already).
 4 if (con.getautocommit()) {
 5     txobject.setmustrestoreautocommit(true);
 6     if (logger.isdebugenabled()) {
 7         logger.debug("switching jdbc connection [" + con + "] to manual commit");
 8     }
 9     con.setautocommit(false);
10 }

有些數據鏈接池提供了關閉事務自動提交的設置，最好在設置鏈接池時就將其關閉。但C3P0沒有提供這一特性，只能依靠spring來設置。
由於JDBC規範規定，當鏈接對象創建時應該處於自動提交模式，這是跨DBMS的缺省值，若是須要,必須顯式的關閉自動提交。C3P0遵照這一規範，讓客戶代碼來顯式的設置須要的提交模式。

鏈接關閉時的是否自動提交

當一個鏈接關閉時，若是有未提交的事務應該如何處理？JDBC規範沒有說起，C3P0默認的策略是回滾任何未提交的事務。這是一個正確的策略，但JDBC驅動提供商之間對此問題並無達成一致。
C3P0的autoCommitOnClose屬性默認是false,沒有十分必要不要動它。或者能夠顯式的設置此屬性爲false，這樣會更明確。

基於註解的聲明式事務管理配置
spring-servlet.xml

1 <!-- transaction support-->
2 <!-- PlatformTransactionMnager -->
3 <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
4     <property name="dataSource" ref="dataSource" />
5 </bean>
6 <!-- enable transaction annotation support -->
7 <tx:annotation-driven transaction-manager="txManager" />

還要在spring-servlet.xml中添加tx名字空間

 1 ...
 2     xmlns:tx="http://www.springframework.org/schema/tx"
 3     xmlns:aop="http://www.springframework.org/schema/aop"
 4     xsi:schemaLocation="
 5     ...
 6  
 7 http://www.springframework.org/schema/tx
 8  
 9  
10 http://www.springframework.org/schema/tx/spring-tx.xsd
11  
12     ...

MyBatis自動參與到spring事務管理中，無需額外配置，只要org.mybatis.spring.SqlSessionFactoryBean引用的數據源與DataSourceTransactionManager引用的數據源一致便可，不然事務管理會不起做用。

另外須要下載依賴包aopalliance.jar放置到WEB-INF/lib目錄下。不然spring初始化時會報異常
java.lang.NoClassDefFoundError: org/aopalliance/intercept/MethodInterceptor

spring事務特性

spring全部的事務管理策略類都繼承自org.springframework.transaction.PlatformTransactionManager接口

1 public interface PlatformTransactionManager {
2  
3   TransactionStatus getTransaction(TransactionDefinition definition)
4     throws TransactionException;
5  
6   void commit(TransactionStatus status) throws TransactionException;
7  
8   void rollback(TransactionStatus status) throws TransactionException;
9 }

其中TransactionDefinition接口定義如下特性：

事務隔離級別

隔離級別是指若干個併發的事務之間的隔離程度。TransactionDefinition 接口中定義了五個表示隔離級別的常量：

• TransactionDefinition.ISOLATION_DEFAULT：這是默認值，表示使用底層數據庫的默認隔離級別。對大部分數據庫而言，一般這值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
• TransactionDefinition.ISOLATION_READ_UNCOMMITTED：該隔離級別表示一個事務能夠讀取另外一個事務修改但尚未提交的數據。該級別不能防止髒讀，不可重複讀和幻讀，所以不多使用該隔離級別。好比PostgreSQL實際上並無此級別。
• TransactionDefinition.ISOLATION_READ_COMMITTED：該隔離級別表示一個事務只能讀取另外一個事務已經提交的數據。該級別能夠防止髒讀，這也是大多數狀況下的推薦值。
• TransactionDefinition.ISOLATION_REPEATABLE_READ：該隔離級別表示一個事務在整個過程當中能夠屢次重複執行某個查詢，而且每次返回的記錄都相同。該級別能夠防止髒讀和不可重複讀。
• TransactionDefinition.ISOLATION_SERIALIZABLE：全部的事務依次逐個執行，這樣事務之間就徹底不可能產生干擾，也就是說，該級別能夠防止髒讀、不可重複讀以及幻讀。可是這將嚴重影響程序的性能。一般狀況下也不會用到該級別。

事務傳播行爲

所謂事務的傳播行爲是指，若是在開始當前事務以前，一個事務上下文已經存在，此時有若干選項能夠指定一個事務性方法的執行行爲。在TransactionDefinition定義中包括了以下幾個表示傳播行爲的常量：

• TransactionDefinition.PROPAGATION_REQUIRED：若是當前存在事務，則加入該事務；若是當前沒有事務，則建立一個新的事務。這是默認值。
• TransactionDefinition.PROPAGATION_REQUIRES_NEW：建立一個新的事務，若是當前存在事務，則把當前事務掛起。
• TransactionDefinition.PROPAGATION_SUPPORTS：若是當前存在事務，則加入該事務；若是當前沒有事務，則以非事務的方式繼續運行。
• TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事務方式運行，若是當前存在事務，則把當前事務掛起。
• TransactionDefinition.PROPAGATION_NEVER：以非事務方式運行，若是當前存在事務，則拋出異常。
• TransactionDefinition.PROPAGATION_MANDATORY：若是當前存在事務，則加入該事務；若是當前沒有事務，則拋出異常。
• TransactionDefinition.PROPAGATION_NESTED：若是當前存在事務，則建立一個事務做爲當前事務的嵌套事務來運行；若是當前沒有事務，則該取值等價於TransactionDefinition.PROPAGATION_REQUIRED。

事務超時

所謂事務超時，就是指一個事務所容許執行的最長時間，若是超過該時間限制但事務尚未完成，則自動回滾事務。在 TransactionDefinition 中以 int 的值來表示超時時間，其單位是秒。

默認設置爲底層事務系統的超時值，若是底層數據庫事務系統沒有設置超時值，那麼就是none，沒有超時限制。

事務只讀屬性

只讀事務用於客戶代碼只讀但不修改數據的情形，只讀事務用於特定情景下的優化，好比使用Hibernate的時候。
默認爲讀寫事務。

spring事務回滾規則

指示spring事務管理器回滾一個事務的推薦方法是在當前事務的上下文內拋出異常。spring事務管理器會捕捉任何未處理的異常，而後依據規則決定是否回滾拋出異常的事務。

默認配置下，spring只有在拋出的異常爲運行時unchecked異常時纔回滾該事務，也就是拋出的異常爲RuntimeException的子類(Errors也會致使事務回滾)，而拋出checked異常則不會致使事務回滾。
能夠明確的配置在拋出那些異常時回滾事務，包括checked異常。也能夠明肯定義那些異常拋出時不回滾事務。

還能夠編程性的經過setRollbackOnly()方法來指示一個事務必須回滾，在調用完setRollbackOnly()後你所能執行的惟一操做就是回滾。

@Transactional註解

@Transactional屬性

屬性	類型	描述
value	String	可選的限定描述符，指定使用的事務管理器
propagation	enum: Propagation	可選的事務傳播行爲設置
isolation	enum: Isolation	可選的事務隔離級別設置
readOnly	boolean	讀寫或只讀事務，默認讀寫
timeout	int (in seconds granularity)	事務超時時間設置
rollbackFor	Class對象數組，必須繼承自Throwable	致使事務回滾的異常類數組
rollbackForClassName	類名數組，必須繼承自Throwable	致使事務回滾的異常類名字數組
noRollbackFor	Class對象數組，必須繼承自Throwable	不會致使事務回滾的異常類數組
noRollbackForClassName	類名數組，必須繼承自Throwable	不會致使事務回滾的異常類名字數組

 

用法

@Transactional 能夠做用於接口、接口方法、類以及類方法上。看成用於類上時，該類的全部 public 方法將都具備該類型的事務屬性，同時，咱們也能夠在方法級別使用該標註來覆蓋類級別的定義。

雖然 @Transactional 註解能夠做用於接口、接口方法、類以及類方法上，可是 Spring 建議不要在接口或者接口方法上使用該註解，由於這隻有在使用基於接口的代理時它纔會生效。另外， @Transactional 註解應該只被應用到 public 方法上，這是由 Spring AOP 的本質決定的。若是你在 protected、private 或者默承認見性的方法上使用 @Transactional 註解，這將被忽略，也不會拋出任何異常。

默認狀況下，只有來自外部的方法調用纔會被AOP代理捕獲，也就是，類內部方法調用本類內部的其餘方法並不會引發事務行爲，即便被調用方法使用@Transactional註解進行修飾。

 1 @Transactional(readOnly = true)
 2 public class DefaultFooService implements FooService {
 3  
 4   public Foo getFoo(String fooName) {
 5     // do something
 6   }
 7  
 8   // these settings have precedence for this method
 9   //方法上註解屬性會覆蓋類註解上的相同屬性
10   @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
11   public void updateFoo(Foo foo) {
12     // do something
13   }
14 }

 

注意的幾點:
1 @Transactional 只能被應用到public方法上, 對於其它非public的方法,若是標記了@Transactional也不會報錯,但方法沒有事務功能.

2用 spring 事務管理器,由spring來負責數據庫的打開,提交,回滾.默認遇到運行期例外(throw new RuntimeException("註釋");)會回滾，即遇到不受檢查（unchecked）的例外時回滾；而遇到須要捕獲的例外(throw new Exception("註釋");)不會回滾,即遇到受檢查的例外（就是非運行時拋出的異常，編譯器會檢查到的異常叫受檢查例外或說受檢查異常）時，需咱們指定方式來讓事務回滾 要想全部異常都回滾,要加上 @Transactional( rollbackFor={Exception.class,其它異常}) .若是讓unchecked例外不回滾： @Transactional(notRollbackFor=RunTimeException.class)
以下:
@Transactional(rollbackFor=Exception.class) //指定回滾,遇到異常Exception時回滾
public void methodName() {
throw new Exception("註釋");

}
@Transactional(noRollbackFor=Exception.class)//指定不回滾,遇到運行期例外(throw new RuntimeException("註釋");)會回滾
public ItimDaoImpl getItemDaoImpl() {
throw new RuntimeException("註釋");
}

三、@Transactional 註解應該只被應用到 public 可見度的方法上。 若是你在 protected、private 或者 package-visible 的方法上使用 @Transactional 註解，它也不會報錯， 可是這個被註解的方法將不會展現已配置的事務設置。

四、@Transactional 註解能夠被應用於接口定義和接口方法、類定義和類的 public 方法上。然而，請注意僅僅 @Transactional 註解的出現不足於開啓事務行爲，它僅僅 是一種元數據，可以被能夠識別 @Transactional 註解和上述的配置適當的具備事務行爲的beans所使用。上面的例子中，其實正是 <tx:annotation-driven/>元素的出現 開啓 了事務行爲。

五、Spring團隊的建議是你在具體的類（或類的方法）上使用 @Transactional 註解，而不要使用在類所要實現的任何接口上。你固然能夠在接口上使用 @Transactional 註解，可是這將只能當你設置了基於接口的代理時它才生效。由於註解是 不能繼承 的，這就意味着若是你正在使用基於類的代理時，那麼事務的設置將不能被基於類的代理所識別，並且對象也將不會被事務代理所包裝（將被確認爲嚴重的）。因 此，請接受Spring團隊的建議而且在具體的類上使用 @Transactional 註解。

 

在實際開發中，對於一組數據庫操做特別是增刪改操做，爲了保證原子性，經過須要用事務來控制，要麼所有成功，要麼所有失敗。Spring中能夠經過註解@Transaction

經常使用的方法以下：

 

@Transactional
public void testTransaction(User user) {
int rowNum = userMapper.insertUser(user);
List<User> userList = userMapper.selectAllUsers();
}
這裏將兩個操做insert和select看成原子操做，若是在testTransaction方法中有異常，則回滾。（注意：這個事務是MySQL層控制，回滾的操做也是MySQL控制的）。

須要注意的問題：

（1）儘量將MySQL執行語句往方法體後面靠：

 

@Transactional
public void testTransaction(User user) {
int rowNum = userMapper.insertUser(user);
doSomething(); // 這個doSomthing 可能耗時較長
List<User> userList = userMapper.selectAllUsers();
}
若是能夠移動的話，能夠將doSomething()可能耗時較長，移動到int rowNum=userMapper.insertUser(user)的前面，即：

@Transactional
public void testTransaction(User user) {
doSomething(); // 這個doSomthing 可能耗時較長
int rowNum = userMapper.insertUser(user);
List<User> userList = userMapper.selectAllUsers();
}
由於，MySQL事務的commit語句是在第一次執行MySQL相關語句開始，一直到方法的結束。

（2）設置事務的超時時間（若是不設置默認是-1是無限長）

 

@Transactional(timeout = 5)
public void testTransaction(User user) throws InterruptedException {
Thread.sleep(2000);
List<User> userList = userMapper.selectAllUsers(); // 耗時：1s
int rowNum = userMapper.insertUser(user); // 耗時 1s
Thread.sleep(3000);
}
加入另外兩個MySQL相關的操做耗時都是1s，則上述事務是不會報超時異常。

timeout的計算的事務超時 = 最後一個MySQL語句耗時 + 以及最後一個MySQL以前的全部耗時。所以，上述耗時爲2s+1s+1s=4s，沒有超過5s，所以不會報事務超時異常，這個須要特別注意，若是想了解具體原理，能夠查看源碼，或者看該文檔：http://jinnianshilongnian.iteye.com/blog/1986023

 

還有特別好的文章：：：：：：：：：：：：：：：：：：：https://blog.csdn.net/fanxb92/article/details/81296005