Spring事務的傳播行為和隔離級別

atlantisholic發表於2012-06-28

事務的傳播行為和隔離級別[transaction behavior. and isolated level]

Spring中事務的定義:
一、Propagation :
  key屬性確定代理應該給哪個方法增加事務行為。這樣的屬性最重要的部份是傳播行為。有以下選項可供使用:
PROPAGATION_REQUIRED--支援當前事務,如果當前沒有事務,就新建一個事務。這是最常見的選擇。
PROPAGATION_SUPPORTS--支援當前事務,如果當前沒有事務,就以非事務方式執行。
PROPAGATION_MANDATORY--支援當前事務,如果當前沒有事務,就丟擲異常。
PROPAGATION_REQUIRES_NEW--新建事務,如果當前存在事務,把當前事務掛起。
PROPAGATION_NOT_SUPPORTED--以非事務方式執行操作,如果當前存在事務,就把當前事務掛起。
PROPAGATION_NEVER--以非事務方式執行,如果當前存在事務,則丟擲異常。

很多人看到事務的傳播行為屬性都不甚瞭解,我昨晚看了j2ee without ejb的時候,看到這裡也不瞭解,甚至重新翻起資料庫系統的教材書,但是也沒有找到對這個的分析。今天搜尋,找到一篇極好的分析文章,雖然這篇文章是重點分析PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRED_NESTED的
解惑 spring 巢狀事務
/**
* @author 王政
* @date 2006-11-24
* @note 轉載自
http://www.iteye.com/topic/35907?page=1
*/
********TransactionDefinition 介面定義*******************
/**   
      * Support a current transaction, create a new one if none exists.   
      * Analogous to EJB transaction attribute of the same name.   
      *

This is typically the default setting of a transaction definition.   
      */   
     int PROPAGATION_REQUIRED = 0;   
  
     /**   
      * Support a current transaction, execute non-transactionally if none exists.   
      * Analogous to EJB transaction attribute of the same name.   
      *

Note: For transaction managers with transaction synchronization,   
      * PROPAGATION_SUPPORTS is slightly different from no transaction at all,   
      * as it defines a transaction scopp that synchronization will apply for.   
      * As a consequence, the same resources (JDBC Connection, Hibernate Session, etc)   
      * will be shared for the entire specified scope. Note that this depends on   
      * the actual synchronization configuration of the transaction manager.   
      * @see org.springframework.transaction.support.AbstractPlatformTransactionManager#setTransactionSynchronization   
      */   
     int PROPAGATION_SUPPORTS = 1;   
  
     /**   
      * Support a current transaction, throw an exception if none exists.   
      * Analogous to EJB transaction attribute of the same name.   
      */   
     int PROPAGATION_MANDATORY = 2;   
  
     /**   
      * Create a new transaction, suspend the current transaction if one exists.   
      * Analogous to EJB transaction attribute of the same name.   
      *

Note: Actual transaction suspension will not work on out-of-the-box   
      * on all transaction managers. This in particular applies to JtaTransactionManager,   
      * which requires the javax.transaction.TransactionManager to be   
      * made available it to it (which is server-specific in standard J2EE).   
      * @see org.springframework.transaction.jta.JtaTransactionManager#setTransactionManager   
      */   
     int PROPAGATION_REQUIRES_NEW = 3;   
  
     /**   
      * Execute non-transactionally, suspend the current transaction if one exists.   
      * Analogous to EJB transaction attribute of the same name.   
      *

Note: Actual transaction suspension will not work on out-of-the-box   
      * on all transaction managers. This in particular applies to JtaTransactionManager,   
      * which requires the javax.transaction.TransactionManager to be   
      * made available it to it (which is server-specific in standard J2EE).   
      * @see org.springframework.transaction.jta.JtaTransactionManager#setTransactionManager   
      */   
     int PROPAGATION_NOT_SUPPORTED = 4;   
  
     /**   
      * Execute non-transactionally, throw an exception if a transaction exists.   
      * Analogous to EJB transaction attribute of the same name.   
      */   
     int PROPAGATION_NEVER = 5;   
  
     /**   
      * Execute within a nested transaction if a current transaction exists,   
      * behave like PROPAGATION_REQUIRED else. There is no analogous feature in EJB.   
      *

Note: Actual creation of a nested transaction will only work on specific   
      * transaction managers. Out of the box, this only applies to the JDBC   
      * DataSourceTransactionManager when working on a JDBC 3.0 driver.   
      * Some JTA providers might support nested transactions as well.   
      * @see org.springframework.jdbc.datasource.DataSourceTransactionManager   
      */   
     int PROPAGATION_NESTED = 6;   

*************************************************************************
在這篇文章裡,他用兩個巢狀的例子輔助分析,我這裡直接引用了。
********************sample***********************
ServiceA {   
       
     /**  
      * 事務屬性配置為 PROPAGATION_REQUIRED  
      */  
     void methodA() {   
         ServiceB.methodB();   
     }   
  
}   
  
ServiceB {   
       
     /**  
      * 事務屬性配置為 PROPAGATION_REQUIRED  
      */    
     void methodB() {   
     }   
       
}      
*************************************************
我們這裡一個個分析吧
1: PROPAGATION_REQUIRED
加入當前正要執行的事務不在另外一個事務裡,那麼就起一個新的事務
比如說,ServiceB.methodB的事務級別定義為PROPAGATION_REQUIRED, 那麼由於執行ServiceA.methodA的時候,
         ServiceA.methodA已經起了事務,這時呼叫ServiceB.methodB,ServiceB.methodB看到自己已經執行在ServiceA.methodA
的事務內部,就不再起新的事務。而假如ServiceA.methodA執行的時候發現自己沒有在事務中,他就會為自己分配一個事務。
這樣,在ServiceA.methodA或者在ServiceB.methodB內的任何地方出現異常,事務都會被回滾。即使ServiceB.methodB的事務已經被
提交,但是ServiceA.methodA在接下來fail要回滾,ServiceB.methodB也要回滾
2:   PROPAGATION_SUPPORTS
如果當前在事務中,即以事務的形式執行,如果當前不再一個事務中,那麼就以非事務的形式執行
這就跟平常用的普通非事務的程式碼只有一點點區別了。不理這個,因為我也沒有覺得有什麼區別
3:   PROPAGATION_MANDATORY
必須在一個事務中執行。也就是說,他只能被一個父事務呼叫。否則,他就要丟擲異常。
4:   PROPAGATION_REQUIRES_NEW
這個就比較繞口了。 比如我們設計ServiceA.methodA的事務級別為PROPAGATION_REQUIRED,ServiceB.methodB的事務級別為PROPAGATION_REQUIRES_NEW,
那麼當執行到ServiceB.methodB的時候,ServiceA.methodA所在的事務就會掛起,ServiceB.methodB會起一個新的事務,等待ServiceB.methodB的事務完成以後,
他才繼續執行。他與PROPAGATION_REQUIRED 的事務區別在於事務的回滾程度了。因為ServiceB.methodB是新起一個事務,那麼就是存在
兩個不同的事務。如果ServiceB.methodB已經提交,那麼ServiceA.methodA失敗回滾,ServiceB.methodB是不會回滾的。如果ServiceB.methodB失敗回滾,
如果他丟擲的異常被ServiceA.methodA捕獲,ServiceA.methodA事務仍然可能提交。
5:   PROPAGATION_NOT_SUPPORTED
當前不支援事務。比如ServiceA.methodA的事務級別是PROPAGATION_REQUIRED ,而ServiceB.methodB的事務級別是PROPAGATION_NOT_SUPPORTED ,
那麼當執行到ServiceB.methodB時,ServiceA.methodA的事務掛起,而他以非事務的狀態執行完,再繼續ServiceA.methodA的事務。
6:   PROPAGATION_NEVER
不能在事務中執行。假設ServiceA.methodA的事務級別是PROPAGATION_REQUIRED, 而ServiceB.methodB的事務級別是PROPAGATION_NEVER ,
那麼ServiceB.methodB就要丟擲異常了。
7:   PROPAGATION_NESTED
理解Nested的關鍵是savepoint。他與PROPAGATION_REQUIRES_NEW的區別是,PROPAGATION_REQUIRES_NEW另起一個事務,將會與他的父事務相互獨立,
而Nested的事務和他的父事務是相依的,他的提交是要等和他的父事務一塊提交的。也就是說,如果父事務最後回滾,他也要回滾的。
而Nested事務的好處是他有一個savepoint。
*****************************************
ServiceA {   
       
     /**  
      * 事務屬性配置為 PROPAGATION_REQUIRED  
      */  
     void methodA() {   
         try {
      //savepoint   
             ServiceB.methodB();    //PROPAGATION_NESTED 級別
         } catch (SomeException) {   
             // 執行其他業務, 如 ServiceC.methodC();   
         }   
     }   
  
}   
********************************************
也就是說ServiceB.methodB失敗回滾,那麼ServiceA.methodA也會回滾到savepoint點上,ServiceA.methodA可以選擇另外一個分支,比如
ServiceC.methodC,繼續執行,來嘗試完成自己的事務。
但是這個事務並沒有在EJB標準中定義。

二、Isolation Level(事務隔離等級):
1、Serializable:最嚴格的級別,事務序列執行,資源消耗最大;

2、REPEATABLE READ:保證了一個事務不會修改已經由另一個事務讀取但未提交(回滾)的資料。避免了“髒讀取”和“不可重複讀取”的情況,但是帶來了更多的效能損失。

3、READ COMMITTED:大多數主流資料庫的預設事務等級,保證了一個事務不會讀到另一個並行事務已修改但未提交的資料,避免了“髒讀取”。該級別適用於大多數系統。

4、Read Uncommitted:保證了讀取過程中不會讀取到非法資料。
隔離級別在於處理多事務的併發問題。
我們知道並行可以提高資料庫的吞吐量和效率,但是並不是所有的併發事務都可以併發執行,這需要檢視資料庫教材的可序列化條件判斷了。
這裡就不闡述。
我們首先說併發中可能發生的3中不討人喜歡的事情
1:   Dirty reads--讀髒資料。也就是說,比如事務A的未提交(還依然快取)的資料被事務B讀走,如果事務A失敗回滾,會導致事務B所讀取的的資料是錯誤的。

2:   non-repeatable reads--資料不可重複讀。比如事務A中兩處讀取資料-total-的值。在第一讀的時候,total是100,然後事務B就把total的資料改成200,事務A再讀一次,結果就發現,total竟然就變成200了,造成事務A資料混亂。

3:   phantom reads--幻象讀資料,這個和non-repeatable reads相似,也是同一個事務中多次讀不一致的問題。但是non-repeatable reads的不一致是因為他所要取的資料集被改變了(比如total的資料),但是phantom reads所要讀的資料的不一致卻不是他所要讀的資料集改變,而是他的條件資料集改變。比如Select account.id where account.name="ppgogo*",第一次讀去了6個符合條件的id,第二次讀取的時候,由於事務b把一個帳號的名字由"dd"改成"ppgogo1",結果取出來了7個資料。
                          Dirty reads          non-repeatable reads            phantom reads
Serializable                     不會                   不會                           不會
REPEATABLE READ           不會                   不會                            會
READ COMMITTED            不會                    會                             會
Read Uncommitted            會                     會                             會

三、readOnly
事務屬性中的readOnly標誌表示對應的事務應該被最優化為只讀事務。這是一個最優化提示。在一些情況下,一些事務策略能夠起到顯著的最優化效果,例如在使用Object/Relational對映工具(如:Hibernate或TopLink)時避免dirty checking(試圖“重新整理”)。
四、Timeout
       在事務屬性中還有定義“timeout”值的選項,指定事務超時為幾秒。在JTA中,這將被簡單地傳遞到J2EE伺服器的事務協調程式,並據此得到相應的解釋。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23071790/viewspace-734087/,如需轉載,請註明出處,否則將追究法律責任。

相關文章