詳解spring事務屬性
阿新 • • 發佈:2018-12-27
Spring宣告式事務讓我們從複雜的事務處理中得到解脫。使得我們再也無需要去處理獲得連線、關閉連線、事務提交和回滾等這些操作。再也無需要我們在與事務相關的方法中處理大量的try…catch…finally程式碼。
我們在使用Spring宣告式事務時,有一個非常重要的概念就是事務屬性。事務屬性通常由事務的傳播行為,事務的隔離級別,事務的超時值和事務只讀標誌組成。我們在進行事務劃分時,需要進行事務定義,也就是配置事務的屬性。
Spring在TransactionDefinition介面中定義這些屬性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事務管理的核心介面。
Java程式碼
getTimeout()方法,它返回事務必須在多少秒內完成。
isReadOnly(),事務是否只讀,事務管理器能夠根據這個返回值進行優化,確保事務是隻讀的。
getIsolationLevel()方法返回事務的隔離級別,事務管理器根據它來控制另外一個事務可以看到本事務內的哪些資料。
在TransactionDefinition介面中定義了五個不同的事務隔離級別
ISOLATION_DEFAULT 這是一個PlatfromTransactionManager預設的隔離級別,使用資料庫預設的事務隔離級別.另外四個與JDBC的隔離級別相對應
ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別,它充許別外一個事務可以看到這個事務未提交的資料。這種隔離級別會產生髒讀,不可重複讀和幻像讀。
例如:
Mary的原工資為1000,財務人員將Mary的工資改為了8000,但未提交事務
Java程式碼
與此同時,Mary正在讀取自己的工資
Java程式碼
Mary發現自己的工資變為了8000,歡天喜地!
而財務發現操作有誤,而回滾了事務,Mary的工資又變為了1000
Java程式碼
像這樣,Mary記取的工資數8000是一個髒資料。
ISOLATION_READ_COMMITTED 保證一個事務修改的資料提交後才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的資料。這種事務隔離級別可以避免髒讀出現,但是可能會出現不可重複讀和幻像讀。
ISOLATION_REPEATABLE_READ 這種事務隔離級別可以防止髒讀,不可重複讀。但是可能出現幻像讀。它除了保證一個事務不能讀取另一個事務未提交的資料外,還保證了避免下面的情況產生(不可重複讀)。
在事務1中,Mary 讀取了自己的工資為1000,操作並沒有完成
Java程式碼
在事務2中,這時財務人員修改了Mary的工資為2000,並提交了事務.
Java程式碼
在事務1中,Mary 再次讀取自己的工資時,工資變為了2000
Java程式碼
在一個事務中前後兩次讀取的結果並不致,導致了不可重複讀。
使用ISOLATION_REPEATABLE_READ可以避免這種情況發生。
ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。除了防止髒讀,不可重複讀外,還避免了幻像讀。
目前工資為1000的員工有10人。
事務1,讀取所有工資為1000的員工。
Java程式碼
這時另一個事務向employee表插入了一條員工記錄,工資也為1000
Java程式碼
事務1再次讀取所有工資為1000的員工
Java程式碼
共讀取到了11條記錄,這就產生了幻像讀。
ISOLATION_SERIALIZABLE能避免這樣的情況發生。但是這樣也耗費了最大的資源。
getPropagationBehavior()返回事務的傳播行為,由是否有一個活動的事務來決定一個事務呼叫。
在TransactionDefinition介面中定義了七個事務傳播行為。
PROPAGATION_REQUIRED 如果存在一個事務,則支援當前事務。如果沒有事務則開啟一個新的事務。
Java程式碼
使用spring宣告式事務,spring使用AOP來支援宣告式事務,會根據事務屬性,自動在方法呼叫之前決定是否開啟一個事務,並在方法執行之後決定事務提交或回滾事務。
單獨呼叫methodB方法
Java程式碼
相當於
Java程式碼
Spring保證在methodB方法中所有的呼叫都獲得到一個相同的連線。在呼叫methodB時,沒有一個存在的事務,所以獲得一個新的連線,開啟了一個新的事務。
單獨呼叫MethodA時,在MethodA內又會呼叫MethodB.
執行效果相當於
Java程式碼
呼叫MethodA時,環境中沒有事務,所以開啟一個新的事務.
當在MethodA中呼叫MethodB時,環境中已經有了一個事務,所以methodB就加入當前事務。
PROPAGATION_SUPPORTS 如果存在一個事務,支援當前事務。如果沒有事務,則非事務的執行。但是對於事務同步的事務管理器,PROPAGATION_SUPPORTS與不使用事務有少許不同。
Java程式碼
單純的呼叫methodB時,methodB方法是非事務的執行的。
當呼叫methdA時,methodB則加入了methodA的事務中,事務地執行。
PROPAGATION_MANDATORY 如果已經存在一個事務,支援當前事務。如果沒有一個活動的事務,則丟擲異常。
Java程式碼
當單獨呼叫methodB時,因為當前沒有一個活動的事務,則會丟擲異常
throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found");
當呼叫methodA時,methodB則加入到methodA的事務中,事務地執行。
PROPAGATION_REQUIRES_NEW 總是開啟一個新的事務。如果一個事務已經存在,則將這個存在的事務掛起。
Java程式碼
當單獨呼叫methodB時,相當於把methodb宣告為REQUIRED。開啟一個新的事務,事務地執行。
當呼叫methodA時
Java程式碼
Java程式碼
在這裡,我把ts1稱為外層事務,ts2稱為內層事務。從上面的程式碼可以看出,ts2與ts1是兩個獨立的事務,互不相干。Ts2是否成功並不依 賴於ts1。如果methodA方法在呼叫methodB方法後的doSomeThingB方法失敗了,而methodB方法所做的結果依然被提交。而除 了methodB之外的其它程式碼導致的結果卻被回滾了。
使用PROPAGATION_REQUIRES_NEW,需要使用JtaTransactionManager作為事務管理器。
PROPAGATION_NOT_SUPPORTED 總是非事務地執行,並掛起任何存在的事務。
Java程式碼
當單獨呼叫methodB時,不啟用任何事務機制,非事務地執行。
當呼叫methodA時,相當於下面的效果
Java程式碼
PROPAGATION_NEVER 總是非事務地執行,如果存在一個活動事務,則丟擲異常
Java程式碼
呼叫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;
Java程式碼
如果單獨呼叫methodB方法,則按REQUIRED屬性執行。
如果呼叫methodA方法,相當於下面的效果
Java程式碼
巢狀事務一個非常重要的概念就是內層事務依賴於外層事務。外層事務失敗時,會回滾內層事務所做的動作。而內層事務操作失敗並不會引起外層事務的回滾。
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應該是我們首先的事務傳播行為。它能夠滿足我們大多數的事務需求。
我們在使用Spring宣告式事務時,有一個非常重要的概念就是事務屬性。事務屬性通常由事務的傳播行為,事務的隔離級別,事務的超時值和事務只讀標誌組成。我們在進行事務劃分時,需要進行事務定義,也就是配置事務的屬性。
Spring在TransactionDefinition介面中定義這些屬性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事務管理的核心介面。
Java程式碼
TransactionDefinition
public interface TransactionDefinition {
int getPropagationBehavior();
int getIsolationLevel();
int getTimeout();
boolean isReadOnly();
}
getTimeout()方法,它返回事務必須在多少秒內完成。
isReadOnly(),事務是否只讀,事務管理器能夠根據這個返回值進行優化,確保事務是隻讀的。
getIsolationLevel()方法返回事務的隔離級別,事務管理器根據它來控制另外一個事務可以看到本事務內的哪些資料。
在TransactionDefinition介面中定義了五個不同的事務隔離級別
ISOLATION_DEFAULT 這是一個PlatfromTransactionManager預設的隔離級別,使用資料庫預設的事務隔離級別.另外四個與JDBC的隔離級別相對應
ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別,它充許別外一個事務可以看到這個事務未提交的資料。這種隔離級別會產生髒讀,不可重複讀和幻像讀。
例如:
Mary的原工資為1000,財務人員將Mary的工資改為了8000,但未提交事務
Java程式碼
Connection con1 = getConnection();
con.setAutoCommit(false);
update employee set salary = 8000 where empId ="Mary";
與此同時,Mary正在讀取自己的工資
Java程式碼
Connection con2 = getConnection();
select salary from employee where empId ="Mary";
con2.commit();
Mary發現自己的工資變為了8000,歡天喜地!
而財務發現操作有誤,而回滾了事務,Mary的工資又變為了1000
Java程式碼
//con1
con1.rollback();
像這樣,Mary記取的工資數8000是一個髒資料。
ISOLATION_READ_COMMITTED 保證一個事務修改的資料提交後才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的資料。這種事務隔離級別可以避免髒讀出現,但是可能會出現不可重複讀和幻像讀。
ISOLATION_REPEATABLE_READ
在事務1中,Mary 讀取了自己的工資為1000,操作並沒有完成
Java程式碼
con1 = getConnection();
select salary from employee empId ="Mary";
在事務2中,這時財務人員修改了Mary的工資為2000,並提交了事務.
Java程式碼
con2 = getConnection();
update employee set salary = 2000;
con2.commit();
在事務1中,Mary 再次讀取自己的工資時,工資變為了2000
Java程式碼
//con1
select salary from employee empId ="Mary";
在一個事務中前後兩次讀取的結果並不致,導致了不可重複讀。
使用ISOLATION_REPEATABLE_READ可以避免這種情況發生。
ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。除了防止髒讀,不可重複讀外,還避免了幻像讀。
目前工資為1000的員工有10人。
事務1,讀取所有工資為1000的員工。
Java程式碼
con1 = getConnection();共讀取10條記錄
Select * from employee where salary =1000;
這時另一個事務向employee表插入了一條員工記錄,工資也為1000
Java程式碼
con2 = getConnection();
Insert into employee(empId,salary) values("Lili",1000);
con2.commit();
事務1再次讀取所有工資為1000的員工
Java程式碼
//con1
select * from employee where salary =1000;
共讀取到了11條記錄,這就產生了幻像讀。
ISOLATION_SERIALIZABLE能避免這樣的情況發生。但是這樣也耗費了最大的資源。
getPropagationBehavior()返回事務的傳播行為,由是否有一個活動的事務來決定一個事務呼叫。
在TransactionDefinition介面中定義了七個事務傳播行為。
PROPAGATION_REQUIRED 如果存在一個事務,則支援當前事務。如果沒有事務則開啟一個新的事務。
Java程式碼
//事務屬性 PROPAGATION_REQUIRED
methodA{
……
methodB();
……
}
//事務屬性 PROPAGATION_REQUIRED
methodB{
……
}
使用spring宣告式事務,spring使用AOP來支援宣告式事務,會根據事務屬性,自動在方法呼叫之前決定是否開啟一個事務,並在方法執行之後決定事務提交或回滾事務。
單獨呼叫methodB方法
Java程式碼
main{
metodB();
}
相當於
Java程式碼
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.
執行效果相當於
Java程式碼
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與不使用事務有少許不同。
Java程式碼
//事務屬性 PROPAGATION_REQUIRED
methodA(){
methodB();
}
//事務屬性 PROPAGATION_SUPPORTS
methodB(){
……
}
單純的呼叫methodB時,methodB方法是非事務的執行的。
當呼叫methdA時,methodB則加入了methodA的事務中,事務地執行。
PROPAGATION_MANDATORY 如果已經存在一個事務,支援當前事務。如果沒有一個活動的事務,則丟擲異常。
Java程式碼
//事務屬性 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 總是開啟一個新的事務。如果一個事務已經存在,則將這個存在的事務掛起。
Java程式碼
//事務屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_REQUIRES_NEW
methodB(){
……
}
當單獨呼叫methodB時,相當於把methodb宣告為REQUIRED。開啟一個新的事務,事務地執行。
當呼叫methodA時
Java程式碼
main(){情況有些大不一樣.相當於下面的效果。
methodA();
}
Java程式碼
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 總是非事務地執行,並掛起任何存在的事務。
Java程式碼
//事務屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_NOT_SUPPORTED
methodB(){
……
}
當單獨呼叫methodB時,不啟用任何事務機制,非事務地執行。
當呼叫methodA時,相當於下面的效果
Java程式碼
main(){使用PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作為事務管理器。
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_NEVER 總是非事務地執行,如果存在一個活動事務,則丟擲異常
Java程式碼
//事務屬性 PROPAGATION_REQUIRED單獨呼叫methodB,則非事務的執行。
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_NEVER
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;
Java程式碼
//事務屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_NESTED
methodB(){
……
}
如果單獨呼叫methodB方法,則按REQUIRED屬性執行。
如果呼叫methodA方法,相當於下面的效果
Java程式碼
main(){當methodB 方法呼叫之前,呼叫setSavepoint方法,儲存當前的狀態到savepoint。如果methodB方法呼叫失敗,則恢復到之前儲存的狀態。但是 需要注意的是,這時的事務並沒有進行提交,如果後續的程式碼(doSomeThingB()方法)呼叫失敗,則回滾包括methodB方法的所有操作。
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{
//釋放資源
}
}
巢狀事務一個非常重要的概念就是內層事務依賴於外層事務。外層事務失敗時,會回滾內層事務所做的動作。而內層事務操作失敗並不會引起外層事務的回滾。
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應該是我們首先的事務傳播行為。它能夠滿足我們大多數的事務需求。