Spring事務屬性具體解釋

Spring。是一個Java開源框架，是為了解決企業應用程序開發復雜性由Rod Johnson創建的。框架的主要優勢之中的一個就是其分層架構，分層架構同意使用者選擇使用哪一個組件，同一時候為 J2EE 應用程序開發提供集成的框架。

Spring使用主要的JavaBean來完畢曾經僅僅可能由EJB完畢的事情。然而。Spring的用途不僅限於server端的開發。從簡單性、可測試性和松耦合的角度而言，不論什么Java應用都能夠從Spring中受益。

Spring聲明式事務讓我們從復雜的事務處理中得到解脫。使得我們再也不必去處理獲得連接、關閉連接、事務提交和回滾等這些操作，再也無需我們在與事務相關的方法中處理大量的try…catch…finally代碼。 
我們在使用Spring聲明式事務時，有一個很重要的概念就是事務屬性。事務屬性通常由事務的傳播行為、事務的隔離級別、事務的超時值、事務僅僅讀標志組成。我們在進行事務划分時，須要進行事務定義，也就是配置事務的屬性。 

Spring在TransactionDefinition接口中定義這些屬性，以供PlatfromTransactionManager（github）使用，PlatfromTransactionManager是spring事務管理的核心接口。

TransactionDefinition.java（spring-tx/src/main/java/org/springframework/transaction/TransactionDefinition.java。github）

 public interface TransactionDefinition {
     int getPropagationBehavior();
     int getIsolationLevel();
     int getTimeout();
     boolean isReadOnly();
 }

1） getPropagationBehavior()： 返回事務的傳播行為，由是否有一個活動的事務來決定一個事務調用。 
2） getTimeout()： 它返回事務必須在多少秒內完畢。

 
3） isReadOnly()： 事務是否僅僅讀，事務管理器可以依據這個返回值進行優化。確保事務是僅僅讀的。 
4） getIsolationLevel()： 返回事務的隔離級別，事務管理器依據它來控制另外一個事務能夠看到本事務內的哪些數據。

1、事務的的隔離級別

在TransactionDefinition接口中，定義了五個不同的事務隔離級別 ：
1） ISOLATION_DEFAULT （默認隔離級別）

這是一個PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別.另外四個與JDBC的隔離級別相相應 

 

2） ISOLATION_READ_UNCOMMITTED （讀未提交）

       這是事務最低的隔離級別。它充許別外一個事務能夠看到這個事務未提交的數據。

這樣的隔離級別會產生臟讀，不可反復讀和幻讀。 比如: 
  Mary的原工資為1000,財務人員將Mary的工資改為了8000。但未提交事務 

 

 Connection con1 = getConnection();
 con.setAutoCommit(false);
 update employee set salary = 8000 where empId ="Mary";

 

與此同一時候，Mary正在讀取自己的工資 

 

 Connection con2 = getConnection();
 select  salary from employee where empId ="Mary";
 con2.commit();

Mary發現自己的工資變為了8000，歡天喜地！ 
而財務發現操作有誤，而回滾了事務,Mary的工資又變為了1000 

 //con1
   con1.rollback();

像這樣,Mary記取的工資數8000是一個臟數據。 

3）ISOLATION_READ_COMMITTED（讀已提交）

該隔離級別保證一個事務改動的數據提交后才干被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數據。這樣的事務隔離級別能夠避免臟讀出現，可是可能會出現不可反復讀和幻像讀。

在事務1中。Mary 讀取了自己的工資為1000,操作並沒有完畢 

 con1 = getConnection();
 select salary from employee empId ="Mary";

在事務2中，這時財務人員改動了Mary的工資為2000,並提交了事務. 

 con2 = getConnection();
 update employee set salary = 2000;
 con2.commit();

在事務1中，Mary 再次讀取自己的工資時。工資變為了2000 

 //con1
 select salary from employee empId ="Mary";

在一個事務中前后兩次讀取的結果並不致。導致了不可反復讀。

4）ISOLATION_REPEATABLE_READ

     這樣的事務隔離級別能夠防止臟讀，不可反復讀。可是可能出現幻像讀。它除了保證一個事務不能讀取還有一個事務未提交的數據外。還保證了避免以下的情況產生(不可反復讀)。

 

眼下工資為1000的員工有10人。 
事務1,讀取全部工資為1000的員工。 

 con1 = getConnection();
 Select * from employee where salary =1000;

共讀取10條記錄 

這時還有一個事務向employee表插入了一條員工記錄。工資也為1000 

 con2 = getConnection();
 Insert into employee(empId,salary) values("Lili",1000);
 con2.commit();

事務1再次讀取全部工資為1000的員工 

 //con1
 select * from employee where salary =1000;

共讀取到了11條記錄，這就產生了幻像讀。 

5）ISOLATION_SERIALIZABLE 

       這是花費最高代價可是最可靠的事務隔離級別。

事務被處理為順序運行。

除了防止臟讀，不可反復讀外。還避免了幻像讀。可是這樣也耗費了最大的資源。 

2、事務的傳播特性

        getPropagationBehavior()返回事務的傳播行為，由是否有一個活動的事務來決定一個事務調用。

 在TransactionDefinition接口中定義了七個事務傳播行為。 

1）PROPAGATION_REQUIRED 

假設存在一個事務，則支持當前事務。假設沒有事務則開啟一個新的事務。

 

 //事務屬性 PROPAGATION_REQUIRED
 methodA{
 ……
 methodB();
 ……
 }

 //事務屬性 PROPAGATION_REQUIRED
 methodB{
    ……
 }

使用spring聲明式事務，spring使用AOP來支持聲明式事務。會依據事務屬性。自己主動在方法調用之前決定是否開啟一個事務。並在方法運行之后決定事務提交或回滾事務。

 

單獨調用methodB方法 

 main{
   metodB();
 }

相當於 

 Main{
 Connection con=null;

    rry{
       con = getConnection();
       con.setAutoCommit(false);
 //方法調用
 methodB();
 //提交事務
 con.commit();
 }
 Catch(RuntimeException ex){
   //回滾事務
   con.rollback();
 }
 finally{
   //釋放資源
   closeCon();
 }
 }

Spring保證在methodB方法中全部的調用都獲得到一個同樣的連接。在調用methodB時。沒有一個存在的事務。所以獲得一個新的連接，開啟了一個新的事務。 

單獨調用MethodA時，在MethodA內又會調用MethodB. 

運行效果相當於 

 main{
    Connection con = null;
    try{
       con = getConnection();
       methodA();
       con.commit();
 }
 cathc(RuntimeException ex){
  con.rollback();
 }
 finally{
   closeCon();
 }
 }

調用MethodA時，環境中沒有事務，所以開啟一個新的事務. 
當在MethodA中調用MethodB時，環境中已經有了一個事務，所以methodB就增加當前事務。 

2）PROPAGATION_SUPPORTS 

假設存在一個事務，支持當前事務。

假設沒有事務，則非事務的運行。可是對於事務同步的事務管理器，PROPAGATION_SUPPORTS與不使用事務有少許不同。

 

 //事務屬性 PROPAGATION_REQUIRED
 methodA(){
   methodB();
 }

 //事務屬性 PROPAGATION_SUPPORTS
 methodB(){
   ……
 }

單純的調用methodB時，methodB方法是非事務的運行的。

 
當調用methdA時,methodB則增加了methodA的事務中,事務地運行。 

3）PROPAGATION_MANDATORY

假設已經存在一個事務，支持當前事務。假設沒有一個活動的事務，則拋出異常。 

 //事務屬性 PROPAGATION_REQUIRED
 methodA(){
   methodB();
 }

 //事務屬性 PROPAGATION_MANDATORY
 methodB(){
   ……
 }

當單獨調用methodB時，由於當前沒有一個活動的事務，則會拋出異常 
throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found"); 

當調用methodA時，methodB則增加到methodA的事務中，事務地運行。 

4） PROPAGATION_REQUIRES_NEW 

總是開啟一個新的事務。假設一個事務已經存在，則將這個存在的事務掛起。

 

 //事務屬性 PROPAGATION_REQUIRED
 methodA(){
   doSomeThingA();
 methodB();
 doSomeThingB();
 }

 //事務屬性 PROPAGATION_REQUIRES_NEW
 methodB(){
   ……
 }

當單獨調用methodB時。相當於把methodb聲明為REQUIRED。

開啟一個新的事務，事務地運行。 

當調用methodA時 

 main(){
   methodA();
 }

情況有些大不一樣.相當於以下的效果。

 

 main(){
  TransactionManager tm = null;
 try{
   //獲得一個JTA事務管理器
    tm = getTransactionManager();
    tm.begin();//開啟一個新的事務
    Transaction ts1 = tm.getTransaction();
    doSomeThing();
    tm.suspend();//掛起當前事務
    try{
      tm.begin();//又一次開啟第二個事務
      Transaction ts2 = tm.getTransaction();
      methodB();
      ts2.commit();//提交第二個事務

    }
   Catch(RunTimeException ex){
      ts2.rollback();//回滾第二個事務
   }
   finally{
     //釋放資源
   }
    //methodB運行完后。復恢第一個事務
    tm.resume(ts1);
 doSomeThingB();
    ts1.commit();//提交第一個事務
 }
 catch(RunTimeException ex){
   ts1.rollback();//回滾第一個事務
 }
 finally{
   //釋放資源
 }
 }

在這里，我把ts1稱為外層事務。ts2稱為內層事務。從上面的代碼能夠看出。ts2與ts1是兩個獨立的事務。互不相干。Ts2是否成功並不依賴於ts1。

假設methodA方法在調用methodB方法后的doSomeThingB方法失敗了，而methodB方法所做的結果依舊被提交。而除了methodB之外的其他代碼導致的結果卻被回滾了。

 
使用PROPAGATION_REQUIRES_NEW,須要使用JtaTransactionManager作為事務管理器。 

5）PROPAGATION_NOT_SUPPORTED 

總是非事務地運行，並掛起不論什么存在的事務。 

 //事務屬性 PROPAGATION_REQUIRED
 methodA(){
   doSomeThingA();
 methodB();
 doSomeThingB();
 }

 //事務屬性 PROPAGATION_NOT_SUPPORTED
 methodB(){
   ……
 }

當單獨調用methodB時。不啟用不論什么事務機制，非事務地運行。 
當調用methodA時，相當於以下的效果 

 main(){
  TransactionManager tm = null;
 try{
   //獲得一個JTA事務管理器
    tm = getTransactionManager();
    tm.begin();//開啟一個新的事務
    Transaction ts1 = tm.getTransaction();
    doSomeThing();
    tm.suspend();//掛起當前事務
      methodB();
    //methodB運行完后，復恢第一個事務
    tm.resume(ts1);
 doSomeThingB();
    ts1.commit();//提交第一個事務
 }
 catch(RunTimeException ex){
   ts1.rollback();//回滾第一個事務
 }
 finally{
   //釋放資源
 }
 }

使用PROPAGATION_NOT_SUPPORTED,也須要使用JtaTransactionManager作為事務管理器。

 

6）PROPAGATION_NEVER 

總是非事務地運行，假設存在一個活動事務，則拋出異常 

 //事務屬性 PROPAGATION_REQUIRED
 methodA(){
   doSomeThingA();
 methodB();
 doSomeThingB();
 }

 //事務屬性 PROPAGATION_NEVER
 methodB(){
   ……
 }

單獨調用methodB，則非事務的運行。 
調用methodA則會拋出異常 
throw new IllegalTransactionStateException( 
"Transaction propagation 'never' but existing transaction found"); 

7）PROPAGATION_NESTED

假設一個活動的事務存在，則執行在一個嵌套的事務中. 假設沒有活動事務, 則按TransactionDefinition.PROPAGATION_REQUIRED 屬性執行 

這是一個嵌套事務,使用JDBC 3.0驅動時,只支持DataSourceTransactionManager作為事務管理器。須要JDBC 驅動的java.sql.Savepoint類。

有一些JTA的事務管理器實現可能也提供了相同的功能。

 

使用PROPAGATION_NESTED，還須要把PlatformTransactionManager的nestedTransactionAllowed屬性設為true; 
而nestedTransactionAllowed屬性值默覺得false; 

 //事務屬性 PROPAGATION_REQUIRED
 methodA(){
   doSomeThingA();
 methodB();
 doSomeThingB();
 }

 //事務屬性 PROPAGATION_NESTED
 methodB(){
   ……
 }

假設單獨調用methodB方法，則按REQUIRED屬性運行。 
假設調用methodA方法，相當於以下的效果 

 main(){
 Connection con = null;
 Savepoint savepoint = null;
 try{
   con = getConnection();
   con.setAutoCommit(false);
   doSomeThingA();
   savepoint = con2.setSavepoint();
   try
       methodB();
   }catch(RuntimeException ex){
      con.rollback(savepoint);
   }
   finally{
     //釋放資源
   }

   doSomeThingB();
   con.commit();
 }
 catch(RuntimeException ex){
   con.rollback();
 }
 finally{
   //釋放資源
 }
 }

當methodB方法調用之前，調用setSavepoint方法。保存當前的狀態到savepoint。假設methodB方法調用失敗，則恢復到之前保存的狀態。可是須要注意的是。這時的事務並沒有進行提交，假設興許的代碼(doSomeThingB()方法)調用失敗。則回滾包含methodB方法的全部操作。 

嵌套事務一個很重要的概念就是內層事務依賴於外層事務。

外層事務失敗時，會回滾內層事務所做的動作。而內層事務操作失敗並不會引起外層事務的回滾。 

PROPAGATION_NESTED 與PROPAGATION_REQUIRES_NEW的差別:它們很類似,都像一個嵌套事務，假設不存在一個活動的事務。都會開啟一個新的事務。使用PROPAGATION_REQUIRES_NEW時。內層事務與外層事務就像兩個獨立的事務一樣，一旦內層事務進行了提交后。外層事務不能對其進行回滾。兩個事務互不影響。兩個事務不是一個真正的嵌套事務。同一時候它須要JTA事務管理器的支持。 
使用PROPAGATION_NESTED時。外層事務的回滾能夠引起內層事務的回滾。

而內層事務的異常並不會導致外層事務的回滾。它是一個真正的嵌套事務。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED時。須要JDBC 3.0以上驅動及1.4以上的JDK版本號支持。其他的JTA TrasactionManager實現可能有不同的支持方式。

 
PROPAGATION_REQUIRED應該是我們首先的事務傳播行為。

它可以滿足我們大多數的事務需求。