spring事務屬性詳解

jopen 11年前發布 | 17K 次閱讀 Spring JEE框架

Spring，是一個Java開源框架，是為了解決企業應用程序開發復雜性由Rod Johnson創建的。框架的主要優勢之一就是其分層架構，分層架構允許使用者選擇使用哪一個組件，同時為 J2EE 應用程序開發提供集成的框架。Spring使用基本的JavaBean來完成以前只可能由EJB完成的事情。然而，Spring的用途不僅限于服務器端的開發。從簡單性、可測試性和松耦合的角度而言，任何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()：返回事務的隔離級別，事務管理器根據它來控制另外一個事務可以看到本事務內的哪些數據。

在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是一個臟數據。
ISOLATION_READ_COMMITTED 保證一個事務修改的數據提交后才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數據。這種事務隔離級別可以避免臟讀出現，但是可能會出現不可重復讀和幻像讀。

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

在事務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";  

在一個事務中前后兩次讀取的結果并不致，導致了不可重復讀。
使用ISOLATION_REPEATABLE_READ可以避免這種情況發生。

ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。除了防止臟讀，不可重復讀外，還避免了幻像讀。

目前工資為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條記錄，這就產生了幻像讀。
ISOLATION_SERIALIZABLE能避免這樣的情況發生。但是這樣也耗費了最大的資源。

getPropagationBehavior()返回事務的傳播行為，由是否有一個活動的事務來決定一個事務調用。
在TransactionDefinition接口中定義了七個事務傳播行為。
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就加入當前事務。

PROPAGATION_SUPPORTS 如果存在一個事務，支持當前事務。如果沒有事務，則非事務的執行。但是對于事務同步的事務管理器，PROPAGATION_SUPPORTS與不使用事務有少許不同。

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

單純的調用methodB時，methodB方法是非事務的執行的。
當調用methdA時,methodB則加入了methodA的事務中,事務地執行。

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

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

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

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

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作為事務管理器。

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作為事務管理器。

PROPAGATION_NEVER 總是非事務地執行，如果存在一個活動事務，則拋出異常

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

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

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應該是我們首先的事務傳播行為。它能夠滿足我們大多數的事務需求。

本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1378089526705.html

Spring JEE框架

spring事務屬性詳解

相關經驗

相關資訊

相關文檔

目錄