Spring 事務機制詳解

Spring事務機制主要包括 聲明式事務和編程式事務,此處側重講解聲明式事務,編程式事務在實際開發中得不到普遍使用,僅供學習參考。java

Spring聲明式事務讓咱們從複雜的事務處理中獲得解脫。使得咱們 再也無須要去處理得到鏈接、關閉鏈接、事務提交和回滾等這些操做。再也無須要咱們在與事務相關的方法中處理大量的try…catch…finally代碼。咱們在使用Spring聲明式事務時,有一個很是重要的概念就是事務屬性。事務屬性一般由事務的傳播行爲,事務的隔離級別,事務的超時值和事務只讀標誌組成。咱們在進行事務劃分時,須要進行事務定義,也就是配置事務的屬性。spring

下面分別詳細講解,事務的四種屬性,僅供諸位學習參考:sql

Spring在TransactionDefinition接口中定義這些屬性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是Spring事務管理的核心接口數據庫

public interface TransactionDefinition {
  int getPropagationBehavior(); //返回事務的傳播行爲。
  int getIsolationLevel(); //返回事務的隔離級別,事務管理器根據它來控制另一個事務能夠看到本事務內的哪些數據。
  int getTimeout(); //返回事務必須在多少秒內完成。
  boolean isReadOnly(); //事務是否只讀,事務管理器可以根據這個返回值進行優化,確保事務是隻讀的。
}
複製代碼
  1. TransactionDefinition接口中定義五個隔離級別:

ISOLATION_DEFAULT 這是一個PlatfromTransactionManager默認的隔離級別,使用數據庫默認的事務隔離級別.另外四個與JDBC的隔離級別相對應;編程

ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別,它充許別外一個事務能夠看到這個事務未提交的數據。這種隔離級別會產生髒讀,不可重複讀和幻像讀。學習

ISOLATION_READ_COMMITTED 保證一個事務修改的數據提交後才能被另一個事務讀取。另一個事務不能讀取該事務未提交的數據。這種事務隔離級別能夠避免髒讀出現,可是可能會出現不可重複讀和幻像讀。優化

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

ISOLATION_SERIALIZABLE 這是花費最高代價可是最可靠的事務隔離級別。事務被處理爲順序執行。除了防止髒讀,不可重複讀外,還避免了幻像讀。code

  1. 在TransactionDefinition接口中定義了七個事務傳播行爲:

(1)PROPAGATION_REQUIRED 若是存在一個事務,則支持當前事務。若是沒有事務則開啓一個新的事務。orm

// 事務屬性 PROPAGATION_REQUIRED
methodA {
   ……
   methodB();
   …… 
}
// 事務屬性 PROPAGATION_REQUIRED
methodB {
   ……
}
複製代碼

使用Spring聲明式事務,spring使用AOP來支持聲明式事務,會根據事務屬性,自動在方法調用以前決定是否開啓一個事務,並在方法執行以後決定事務提交或回滾事務。

單獨調用methodB方法:

main {
   metodB();
}
至關於
Main {
   Connection con=null;
   try{
     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();
   } catch(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() {
   ……
}
複製代碼
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_NOT_SUPPORTED,也須要使用JtaTransactionManager做爲事務管理器。

(6)PROPAGATION_NEVER 老是非事務地執行,若是存在一個活動事務,則拋出異常;

(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_REQUIRES_NEW 啓動一個新的, 不依賴於環境的 "內部" 事務。這個事務將被徹底 commited 或 rolled back 而不依賴於外部事務, 它擁有本身的隔離範圍, 本身的鎖, 等等. 當內部事務開始執行時, 外部事務將被掛起, 內務事務結束時, 外部事務將繼續執行。

另外一方面, PROPAGATION_NESTED 開始一個 "嵌套的" 事務, 它是已經存在事務的一個真正的子事務. 潛套事務開始執行時, 它將取得一個 savepoint. 若是這個嵌套事務失敗, 咱們將回滾到此 savepoint. 潛套事務是外部事務的一部分, 只有外部事務結束後它纔會被提交。

因而可知, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大區別在於, PROPAGATION_REQUIRES_NEW 徹底是一個新的事務, 而 PROPAGATION_NESTED 則是外部事務的子事務, 若是外部事務 commit, 潛套事務也會被 commit, 這個規則一樣適用於 roll back。PROPAGATION_REQUIRED應該是咱們首先的事務傳播行爲。它可以知足咱們大多數的事務需求。

相關文章
相關標籤/搜索