Spring聲明式事務(wù)讓我們從復(fù)雜的事務(wù)處理中得到解脫。使得我們再也無需要去處理獲得連接、關(guān)閉連接、事務(wù)提交和回滾等這些操作。再也無需要我們在與事務(wù)相關(guān)的方法中處理大量的try…catch…finally代碼。
我們在使用Spring聲明式事務(wù)時,有一個非常重要的概念就是事務(wù)屬性。事務(wù)屬性通常由事務(wù)的傳播行為,事務(wù)的隔離級別,事務(wù)的超時值和事務(wù)只讀標(biāo)志組成。我們在進(jìn)行事務(wù)劃分時,需要進(jìn)行事務(wù)定義,也就是配置事務(wù)的屬性。
Spring在
TransactionDefinition接口中定義這些屬性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事務(wù)管理的核心接口。
- TransactionDefinition
- public interface TransactionDefinition {
- int getPropagationBehavior();
- int getIsolationLevel();
- int getTimeout();
- boolean isReadOnly();
- }
TransactionDefinition
public interface TransactionDefinition {
int getPropagationBehavior();
int getIsolationLevel();
int getTimeout();
boolean isReadOnly();
}
getTimeout()方法,它返回事務(wù)必須在多少秒內(nèi)完成。
isReadOnly(),事務(wù)是否只讀,事務(wù)管理器能夠根據(jù)這個返回值進(jìn)行優(yōu)化,確保事務(wù)是只讀的。
getIsolationLevel()方法返回事務(wù)的隔離級別,事務(wù)管理器根據(jù)它來控制另外一個事務(wù)可以看到本事務(wù)內(nèi)的哪些數(shù)據(jù)。
在TransactionDefinition接口中定義了五個不同的事務(wù)隔離級別
ISOLATION_DEFAULT 這是一個PlatfromTransactionManager默認(rèn)的隔離級別,使用數(shù)據(jù)庫默認(rèn)的事務(wù)隔離級別.另外四個與JDBC的隔離級別相對應(yīng)
ISOLATION_READ_UNCOMMITTED 這是事務(wù)最低的隔離級別,它充許別外一個事務(wù)可以看到這個事務(wù)未提交的數(shù)據(jù)。這種隔離級別會產(chǎn)生臟讀,不可重復(fù)讀和幻像讀。
例如:
Mary的原工資為1000,財務(wù)人員將Mary的工資改為了8000,但未提交事務(wù)
- Connection con1 = getConnection();
- con.setAutoCommit(false);
- update employee set salary = 8000 where empId ="Mary";
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();
Connection con2 = getConnection();
select salary from employee where empId ="Mary";
con2.commit();
Mary發(fā)現(xiàn)自己的工資變?yōu)榱?000,歡天喜地!
而財務(wù)發(fā)現(xiàn)操作有誤,而回滾了事務(wù),Mary的工資又變?yōu)榱?000
//con1
con1.rollback();
像這樣,Mary記取的工資數(shù)8000是一個臟數(shù)據(jù)。
ISOLATION_READ_COMMITTED 保證一個事務(wù)修改的數(shù)據(jù)提交后才能被另外一個事務(wù)讀取。另外一個事務(wù)不能讀取該事務(wù)未提交的數(shù)據(jù)。這種事務(wù)隔離級別可以避免臟讀出現(xiàn),但是可能會出現(xiàn)不可重復(fù)讀和幻像讀。
ISOLATION_REPEATABLE_READ 這種事務(wù)隔離級別可以防止臟讀,不可重復(fù)讀。但是可能出現(xiàn)幻像讀。它除了保證一個事務(wù)不能讀取另一個事務(wù)未提交的數(shù)據(jù)外,還保證了避免下面的情況產(chǎn)生(不可重復(fù)讀)。
在事務(wù)1中,Mary 讀取了自己的工資為1000,操作并沒有完成
- con1 = getConnection();
- select salary from employee empId ="Mary";
con1 = getConnection();
select salary from employee empId ="Mary";
在事務(wù)2中,這時財務(wù)人員修改了Mary的工資為2000,并提交了事務(wù).
- con2 = getConnection();
- update employee set salary = 2000;
- con2.commit();
con2 = getConnection();
update employee set salary = 2000;
con2.commit();
在事務(wù)1中,Mary 再次讀取自己的工資時,工資變?yōu)榱?000
-
- select salary from employee empId ="Mary";
//con1
select salary from employee empId ="Mary";
在一個事務(wù)中前后兩次讀取的結(jié)果并不致,導(dǎo)致了不可重復(fù)讀。
使用ISOLATION_REPEATABLE_READ可以避免這種情況發(fā)生。
ISOLATION_SERIALIZABLE 這是花費(fèi)最高代價但是最可靠的事務(wù)隔離級別。事務(wù)被處理為順序執(zhí)行。除了防止臟讀,不可重復(fù)讀外,還避免了幻像讀。
目前工資為1000的員工有10人。
事務(wù)1,讀取所有工資為1000的員工。
- con1 = getConnection();
- Select * from employee where salary =1000;
con1 = getConnection();
Select * from employee where salary =1000;
共讀取10條記錄
這時另一個事務(wù)向employee表插入了一條員工記錄,工資也為1000
- con2 = getConnection();
- Insert into employee(empId,salary) values("Lili",1000);
- con2.commit();
con2 = getConnection();
Insert into employee(empId,salary) values("Lili",1000);
con2.commit();
事務(wù)1再次讀取所有工資為1000的員工
-
- select * from employee where salary =1000;
//con1
select * from employee where salary =1000;
共讀取到了11條記錄,這就產(chǎn)生了幻像讀。
ISOLATION_SERIALIZABLE能避免這樣的情況發(fā)生。但是這樣也耗費(fèi)了最大的資源。
getPropagationBehavior()返回事務(wù)的傳播行為,由是否有一個活動的事務(wù)來決定一個事務(wù)調(diào)用。
在TransactionDefinition接口中定義了七個事務(wù)傳播行為。
PROPAGATION_REQUIRED 如果存在一個事務(wù),則支持當(dāng)前事務(wù)。如果沒有事務(wù)則開啟一個新的事務(wù)。
-
- methodA{
- ……
- methodB();
- ……
- }
-
-
- methodB{
- ……
- }
//事務(wù)屬性 PROPAGATION_REQUIRED
methodA{
……
methodB();
……
}
//事務(wù)屬性 PROPAGATION_REQUIRED
methodB{
……
}
使用spring聲明式事務(wù),spring使用AOP來支持聲明式事務(wù),會根據(jù)事務(wù)屬性,自動在方法調(diào)用之前決定是否開啟一個事務(wù),并在方法執(zhí)行之后決定事務(wù)提交或回滾事務(wù)。
單獨(dú)調(diào)用methodB方法
main{
metodB();
}
相當(dāng)于
- Main{
- Connection con=null;
-
- rry{
- con = getConnection();
- con.setAutoCommit(false);
-
- methodB();
-
- con.commit();
- }
- Catch(RuntimeException ex){
-
- con.rollback();
- }
- finally{
-
- closeCon();
- }
- }
Main{
Connection con=null;
rry{
con = getConnection();
con.setAutoCommit(false);
//方法調(diào)用
methodB();
//提交事務(wù)
con.commit();
}
Catch(RuntimeException ex){
//回滾事務(wù)
con.rollback();
}
finally{
//釋放資源
closeCon();
}
}
Spring保證在methodB方法中所有的調(diào)用都獲得到一個相同的連接。在調(diào)用methodB時,沒有一個存在的事務(wù),所以獲得一個新的連接,開啟了一個新的事務(wù)。
單獨(dú)調(diào)用MethodA時,在MethodA內(nèi)又會調(diào)用MethodB.
執(zhí)行效果相當(dāng)于
- main{
- Connection con = null;
- try{
- con = getConnection();
- methodA();
- con.commit();
- }
- cathc(RuntimeException ex){
- con.rollback();
- }
- finally{
- closeCon();
- }
- }
main{
Connection con = null;
try{
con = getConnection();
methodA();
con.commit();
}
cathc(RuntimeException ex){
con.rollback();
}
finally{
closeCon();
}
}
調(diào)用MethodA時,環(huán)境中沒有事務(wù),所以開啟一個新的事務(wù).
當(dāng)在MethodA中調(diào)用MethodB時,環(huán)境中已經(jīng)有了一個事務(wù),所以methodB就加入當(dāng)前事務(wù)。
PROPAGATION_SUPPORTS 如果存在一個事務(wù),支持當(dāng)前事務(wù)。如果沒有事務(wù),則非事務(wù)的執(zhí)行。但是對于事務(wù)同步的事務(wù)管理器,PROPAGATION_SUPPORTS與不使用事務(wù)有少許不同。
-
- methodA(){
- methodB();
- }
-
-
- methodB(){
- ……
- }
//事務(wù)屬性 PROPAGATION_REQUIRED
methodA(){
methodB();
}
//事務(wù)屬性 PROPAGATION_SUPPORTS
methodB(){
……
}
單純的調(diào)用methodB時,methodB方法是非事務(wù)的執(zhí)行的。
當(dāng)調(diào)用methdA時,methodB則加入了methodA的事務(wù)中,事務(wù)地執(zhí)行。
PROPAGATION_MANDATORY 如果已經(jīng)存在一個事務(wù),支持當(dāng)前事務(wù)。如果沒有一個活動的事務(wù),則拋出異常。
-
- methodA(){
- methodB();
- }
-
-
- methodB(){
- ……
- }
//事務(wù)屬性 PROPAGATION_REQUIRED
methodA(){
methodB();
}
//事務(wù)屬性 PROPAGATION_MANDATORY
methodB(){
……
}
當(dāng)單獨(dú)調(diào)用methodB時,因為當(dāng)前沒有一個活動的事務(wù),則會拋出異常
throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found");
當(dāng)調(diào)用methodA時,methodB則加入到methodA的事務(wù)中,事務(wù)地執(zhí)行。
PROPAGATION_REQUIRES_NEW 總是開啟一個新的事務(wù)。如果一個事務(wù)已經(jīng)存在,則將這個存在的事務(wù)掛起。
-
- methodA(){
- doSomeThingA();
- methodB();
- doSomeThingB();
- }
-
-
- methodB(){
- ……
- }
//事務(wù)屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務(wù)屬性 PROPAGATION_REQUIRES_NEW
methodB(){
……
}
當(dāng)單獨(dú)調(diào)用methodB時,相當(dāng)于把methodb聲明為REQUIRED。開啟一個新的事務(wù),事務(wù)地執(zhí)行。
當(dāng)調(diào)用methodA時
main(){
methodA();
}
情況有些大不一樣.相當(dāng)于下面的效果。
- main(){
- TransactionManager tm = null;
- try{
-
- 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{
-
- }
-
- tm.resume(ts1);
- doSomeThingB();
- ts1.commit();
- }
- catch(RunTimeException ex){
- ts1.rollback();
- }
- finally{
-
- }
- }
main(){
TransactionManager tm = null;
try{
//獲得一個JTA事務(wù)管理器
tm = getTransactionManager();
tm.begin();//開啟一個新的事務(wù)
Transaction ts1 = tm.getTransaction();
doSomeThing();
tm.suspend();//掛起當(dāng)前事務(wù)
try{
tm.begin();//重新開啟第二個事務(wù)
Transaction ts2 = tm.getTransaction();
methodB();
ts2.commit();//提交第二個事務(wù)
}
Catch(RunTimeException ex){
ts2.rollback();//回滾第二個事務(wù)
}
finally{
//釋放資源
}
//methodB執(zhí)行完后,復(fù)恢第一個事務(wù)
tm.resume(ts1);
doSomeThingB();
ts1.commit();//提交第一個事務(wù)
}
catch(RunTimeException ex){
ts1.rollback();//回滾第一個事務(wù)
}
finally{
//釋放資源
}
}
在這里,我把ts1稱為外層事務(wù),ts2稱為內(nèi)層事務(wù)。從上面的代碼可以看出,ts2與ts1是兩個獨(dú)立的事務(wù),互不相干。Ts2是否成功并不依賴于ts1。如果methodA方法在調(diào)用methodB方法后的doSomeThingB方法失敗了,而methodB方法所做的結(jié)果依然被提交。而除了methodB之外的其它代碼導(dǎo)致的結(jié)果卻被回滾了。
使用PROPAGATION_REQUIRES_NEW,需要使用JtaTransactionManager作為事務(wù)管理器。
PROPAGATION_NOT_SUPPORTED 總是非事務(wù)地執(zhí)行,并掛起任何存在的事務(wù)。
-
- methodA(){
- doSomeThingA();
- methodB();
- doSomeThingB();
- }
-
-
- methodB(){
- ……
- }
//事務(wù)屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務(wù)屬性 PROPAGATION_NOT_SUPPORTED
methodB(){
……
}
當(dāng)單獨(dú)調(diào)用methodB時,不啟用任何事務(wù)機(jī)制,非事務(wù)地執(zhí)行。
當(dāng)調(diào)用methodA時,相當(dāng)于下面的效果
- main(){
- TransactionManager tm = null;
- try{
-
- tm = getTransactionManager();
- tm.begin();
- Transaction ts1 = tm.getTransaction();
- doSomeThing();
- tm.suspend();
- methodB();
-
- tm.resume(ts1);
- doSomeThingB();
- ts1.commit();
- }
- catch(RunTimeException ex){
- ts1.rollback();
- }
- finally{
-
- }
- }
main(){
TransactionManager tm = null;
try{
//獲得一個JTA事務(wù)管理器
tm = getTransactionManager();
tm.begin();//開啟一個新的事務(wù)
Transaction ts1 = tm.getTransaction();
doSomeThing();
tm.suspend();//掛起當(dāng)前事務(wù)
methodB();
//methodB執(zhí)行完后,復(fù)恢第一個事務(wù)
tm.resume(ts1);
doSomeThingB();
ts1.commit();//提交第一個事務(wù)
}
catch(RunTimeException ex){
ts1.rollback();//回滾第一個事務(wù)
}
finally{
//釋放資源
}
}
使用PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作為事務(wù)管理器。
PROPAGATION_NEVER 總是非事務(wù)地執(zhí)行,如果存在一個活動事務(wù),則拋出異常
-
- methodA(){
- doSomeThingA();
- methodB();
- doSomeThingB();
- }
-
-
- methodB(){
- ……
- }
//事務(wù)屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務(wù)屬性 PROPAGATION_NEVER
methodB(){
……
}
單獨(dú)調(diào)用methodB,則非事務(wù)的執(zhí)行。
調(diào)用methodA則會拋出異常
throw new IllegalTransactionStateException(
"Transaction propagation 'never' but existing transaction found");
PROPAGATION_NESTED如果一個活動的事務(wù)存在,則運(yùn)行在一個嵌套的事務(wù)中. 如果沒有活動事務(wù), 則按TransactionDefinition.PROPAGATION_REQUIRED 屬性執(zhí)行
這是一個嵌套事務(wù),使用JDBC 3.0驅(qū)動時,僅僅支持DataSourceTransactionManager作為事務(wù)管理器。需要JDBC 驅(qū)動的java.sql.Savepoint類。有一些JTA的事務(wù)管理器實(shí)現(xiàn)可能也提供了同樣的功能。
使用PROPAGATION_NESTED,還需要把PlatformTransactionManager的nestedTransactionAllowed屬性設(shè)為true;
而nestedTransactionAllowed屬性值默認(rèn)為false;
-
- methodA(){
- doSomeThingA();
- methodB();
- doSomeThingB();
- }
-
-
- methodB(){
- ……
- }
//事務(wù)屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務(wù)屬性 PROPAGATION_NESTED
methodB(){
……
}
如果單獨(dú)調(diào)用methodB方法,則按REQUIRED屬性執(zhí)行。
如果調(diào)用methodA方法,相當(dāng)于下面的效果
- 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{
-
- }
- }
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{
//釋放資源
}
}
當(dāng)methodB方法調(diào)用之前,調(diào)用setSavepoint方法,保存當(dāng)前的狀態(tài)到savepoint。如果methodB方法調(diào)用失敗,則恢復(fù)到之前保存的狀態(tài)。但是需要注意的是,這時的事務(wù)并沒有進(jìn)行提交,如果后續(xù)的代碼(doSomeThingB()方法)調(diào)用失敗,則回滾包括methodB方法的所有操作。
嵌套事務(wù)一個非常重要的概念就是內(nèi)層事務(wù)依賴于外層事務(wù)。外層事務(wù)失敗時,會回滾內(nèi)層事務(wù)所做的動作。而內(nèi)層事務(wù)操作失敗并不會引起外層事務(wù)的回滾。
PROPAGATION_NESTED 與PROPAGATION_REQUIRES_NEW的區(qū)別:它們非常類似,都像一個嵌套事務(wù),如果不存在一個活動的事務(wù),都會開啟一個新的事務(wù)。使用PROPAGATION_REQUIRES_NEW時,內(nèi)層事務(wù)與外層事務(wù)就像兩個獨(dú)立的事務(wù)一樣,一旦內(nèi)層事務(wù)進(jìn)行了提交后,外層事務(wù)不能對其進(jìn)行回滾。兩個事務(wù)互不影響。兩個事務(wù)不是一個真正的嵌套事務(wù)。同時它需要JTA事務(wù)管理器的支持。
使用PROPAGATION_NESTED時,外層事務(wù)的回滾可以引起內(nèi)層事務(wù)的回滾。而內(nèi)層事務(wù)的異常并不會導(dǎo)致外層事務(wù)的回滾,它是一個真正的嵌套事務(wù)。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED時,需要JDBC 3.0以上驅(qū)動及1.4以上的JDK版本支持。其它的JTA TrasactionManager實(shí)現(xiàn)可能有不同的支持方式。
PROPAGATION_REQUIRED應(yīng)該是我們首先的事務(wù)傳播行為。它能夠滿足我們大多數(shù)的事務(wù)需求。
轉(zhuǎn)載地址:http://www.javaeye.com/topic/78674
posted on 2009-06-26 17:55
Werther 閱讀(187)
評論(0) 編輯 收藏