解惑 spring 嵌套事務

時間  2019-12-12
標籤 解惑 spring 嵌套 事務 欄目 Spring 简体版
原文   原文鏈接

/** 
  * @author 王政 
  * @date 2006-11-24 
  * @note 轉載請註明出處 
  */ 

   在全部使用 spring 的應用中, 聲明式事務管理多是使用率最高的功能了, 可是, 從我觀察到的狀況看, 
絕大多數人並不能深入理解事務聲明中不一樣事務傳播屬性配置的的含義, 讓咱們來看一下 TransactionDefinition 接口中的定義 
Java代碼java

/** 
     * Support a current transaction, create a new one if none exists. 
     * Analogous to EJB transaction attribute of the same name. 
     * <p>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. 
     * <p>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. 
     * <p>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 <code>javax.transaction.TransactionManager</code> 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. 
     * <p>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 <code>javax.transaction.TransactionManager</code> 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. 
     * <p>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;

咱們能夠看到, 在 spring 中一共定義了六種事務傳播屬性, 若是你以爲看起來不夠直觀, 那麼我來轉貼一個滿大街都有的翻譯spring

引用sql

PROPAGATION_REQUIRED -- 支持當前事務，若是當前沒有事務，就新建一個事務。這是最多見的選擇。 
PROPAGATION_SUPPORTS -- 支持當前事務，若是當前沒有事務，就以非事務方式執行。 
PROPAGATION_MANDATORY -- 支持當前事務，若是當前沒有事務，就拋出異常。 
PROPAGATION_REQUIRES_NEW -- 新建事務，若是當前存在事務，把當前事務掛起。 
PROPAGATION_NOT_SUPPORTED -- 以非事務方式執行操做，若是當前存在事務，就把當前事務掛起。 
PROPAGATION_NEVER -- 以非事務方式執行，若是當前存在事務，則拋出異常。 
PROPAGATION_NESTED -- 若是當前存在事務，則在嵌套事務內執行。若是當前沒有事務，則進行與PROPAGATION_REQUIRED相似的操做。 
前六個策略相似於EJB CMT，第七個（PROPAGATION_NESTED）是Spring所提供的一個特殊變量。 
它要求事務管理器或者使用JDBC 3.0 Savepoint API提供嵌套事務行爲（如Spring的DataSourceTransactionManager）

在我所見過的誤解中, 最多見的是下面這種: app

引用ide

假若有兩個業務接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一個方法實現以下 

/** 
* 事務屬性配置爲 PROPAGATION_REQUIRED 
*/ 
void methodA() { 
// 調用 ServiceB 的方法 
ServiceB.methodB(); 
} 

那麼若是 ServiceB 的 methodB  若是配置了事務, 就必須配置爲 PROPAGATION_NESTED
這種想法可能害了很多人, 認爲 Service 之間應該避免互相調用, 其實根本不用擔憂這點，PROPAGATION_REQUIRED 已經說得很明白, 
若是當前線程中已經存在事務, 方法調用會加入此事務, 果當前沒有事務，就新建一個事務, 因此 ServiceB#methodB() 的事務只要遵循最普通的規則配置爲 PROPAGATION_REQUIRED 便可, 若是 ServiceB#methodB (咱們稱之爲內部事務, 爲下文打下基礎) 拋了異常, 那麼 ServiceA#methodA(咱們稱之爲外部事務) 若是沒有特殊配置此異常時事務提交 (即 +MyCheckedException的用法), 那麼整個事務是必定要 rollback 的, 什麼 Service 只能調 Dao 之類的言論純屬無稽之談, spring 只負責配置了事務屬性方法的攔截, 它怎麼知道你這個方法是在 Service 仍是 Dao 裏 ? 

     說了這麼半天, 那到底什麼是真正的事務嵌套呢, 解釋以前咱們來看一下  Juergen Hoeller 的原話 

Juergen Hoeller 寫道
PROPAGATION_REQUIRES_NEW starts a new, independent "inner" transaction for the given scope. This transaction will be committed or rolled back completely independent from the outer transaction, having its own isolation scope, its own set of locks, etc. The outer transaction will get suspended at the beginning of the inner one, and resumed once the inner one has completed. 

Such independent inner transactions are for example used for id generation through manual sequences, where the access to the sequence table should happen in its own transactions, to keep the lock there as short as possible. The goal there is to avoid tying the sequence locks to the (potentially much longer running) outer transaction, with the sequence lock not getting released before completion of the outer transaction. 

PROPAGATION_NESTED on the other hand starts a "nested" transaction, which is a true subtransaction of the existing one. What will happen is that a savepoint will be taken at the start of the nested transaction. íf the nested transaction fails, we will roll back to that savepoint. The nested transaction is part of of the outer transaction, so it will only be committed at the end of of the outer transaction. 

Nested transactions essentially allow to try some execution subpaths as subtransactions: rolling back to the state at the beginning of the failed subpath, continuing with another subpath or with the main execution path there - all within one isolated transaction, and not losing any previous work done within the outer transaction. 

For example, consider parsing a very large input file consisting of account transfer blocks: The entire file should essentially be parsed within one transaction, with one single commit at the end. But if a block fails, its transfers need to be rolled back, writing a failure marker somewhere. You could either start over the entire transaction every time a block fails, remembering which blocks to skip - or you mark each block as a nested transaction, only rolling back that specific set of operations, keeping the previous work of the outer transaction. The latter is of course much more efficient, in particular when a block at the end of the file fails.

Juergen Hoeller 寫道函數

Rolling back the entire transaction is the choice of the demarcation code/config that started the outer transaction. 

So if an inner transaction throws an exception and is supposed to be rolled back (according to the rollback rules), the transaction will get rolled back to the savepoint taken at the start of the inner transaction. The immediate calling code can then decide to catch the exception and proceed down some other path within the outer transaction. 

If the code that called the inner transaction lets the exception propagate up the call chain, the exception will eventually reach the demarcation code of the outer transaction. At that point, the rollback rules of the outer transaction decide whether to trigger a rollback. That would be a rollback of the entire outer transaction then. 

So essentially, it depends on your exception handling. If you catch the exception thrown by the inner transaction, you can proceed down some other path within the outer transaction. If you let the exception propagate up the call chain, it's eventually gonna cause a rollback of the entire outer transaction.

也就是說, 最容易弄混淆的實際上是 PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED, 那麼這兩種方式又有何區別呢? 我簡單的翻譯一下 Juergen Hoeller 的話 : 
    
    PROPAGATION_REQUIRES_NEW 啓動一個新的, 不依賴於環境的 "內部" 事務. 這個事務將被徹底 commited 或 rolled back 而不依賴於外部事務, 它擁有本身的隔離範圍, 本身的鎖, 等等. 當內部事務開始執行時, 外部事務將被掛起, 內務事務結束時, 外部事務將繼續執行. 


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

    因而可知, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大區別在於, PROPAGATION_REQUIRES_NEW 徹底是一個新的事務, 而 PROPAGATION_NESTED 則是外部事務的子事務, 若是外部事務 commit, 潛套事務也會被 commit, 這個規則一樣適用於 roll back. 
    
    
    那麼外部事務如何利用嵌套事務的 savepoint 特性呢, 咱們用代碼來講話 
    ui

Java代碼this

ServiceA {  
      
    /** 
     * 事務屬性配置爲 PROPAGATION_REQUIRED 
     */  
    void methodA() {  
        ServiceB.methodB();  
    }  
  
}  
  
ServiceB {  
      
    /** 
     * 事務屬性配置爲 PROPAGATION_REQUIRES_NEW 
     */   
    void methodB() {  
    }  
      
}

這種狀況下, 由於 ServiceB#methodB 的事務屬性爲 PROPAGATION_REQUIRES_NEW, 因此二者不會發生任何關係, ServiceA#methodA 和 ServiceB#methodB 不會由於對方的執行狀況而影響事務的結果, 由於它們根本就是兩個事務, 在 ServiceB#methodB 執行時 ServiceA#methodA 的事務已經掛起了 (關於事務掛起的內容已經超出了本文的討論範圍, 有時間我會再寫一些掛起的文章) . 

那麼 PROPAGATION_NESTED 又是怎麼回事呢? 繼續看代碼 
Java代碼.net

ServiceA {  
      
    /** 
     * 事務屬性配置爲 PROPAGATION_REQUIRED 
     */  
    void methodA() {  
        ServiceB.methodB();  
    }  
  
}  
  
ServiceB {  
      
    /** 
     * 事務屬性配置爲 PROPAGATION_NESTED 
     */   
    void methodB() {  
    }  
      
}

如今的狀況就變得比較複雜了, ServiceB#methodB 的事務屬性被配置爲 PROPAGATION_NESTED, 此時二者之間又將如何協做呢? 從 Juergen Hoeller 的原話中咱們能夠找到答案, ServiceB#methodB 若是 rollback, 那麼內部事務(即 ServiceB#methodB) 將回滾到它執行前的 SavePoint(注意, 這是本文中第一次提到它, 潛套事務中最核心的概念), 而外部事務(即 ServiceA#methodA) 能夠有如下兩種處理方式: prototype

1. 改寫 ServiceA 以下 
Java代碼

ServiceA {  
      
    /** 
     * 事務屬性配置爲 PROPAGATION_REQUIRED 
     */  
    void methodA() {  
        try {  
            ServiceB.methodB();  
        } catch (SomeException) {  
            // 執行其餘業務, 如 ServiceC.methodC();  
        }  
    }  
  
}

這種方式也是潛套事務最有價值的地方, 它起到了分支執行的效果, 若是 ServiceB.methodB 失敗, 那麼執行 ServiceC.methodC(), 而 ServiceB.methodB 已經回滾到它執行以前的 SavePoint, 因此不會產生髒數據(至關於此方法從未執行過), 這種特性能夠用在某些特殊的業務中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都沒有辦法作到這一點. (題外話 : 看到這種代碼, 彷佛似曾相識, 想起了 prototype.js 中的 Try 函數 ) 

2. 代碼不作任何修改, 那麼若是內部事務(即 ServiceB#methodB) rollback, 那麼首先 ServiceB.methodB 回滾到它執行以前的 SavePoint(在任何狀況下都會如此), 
   外部事務(即 ServiceA#methodA) 將根據具體的配置決定本身是 commit 仍是 rollback (+MyCheckedException). 
   
   
上面大體講述了潛套事務的使用場景, 下面咱們來看如何在 spring 中使用 PROPAGATION_NESTED, 首先來看 AbstractPlatformTransactionManager 
 

Java代碼

/** 
 * Create a TransactionStatus for an existing transaction. 
 */  
private TransactionStatus handleExistingTransaction(  
        TransactionDefinition definition, Object transaction, boolean debugEnabled)  
        throws TransactionException {  
  
   ... 省略  
  
    if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {  
        if (!isNestedTransactionAllowed()) {  
            throw new NestedTransactionNotSupportedException(  
                    "Transaction manager does not allow nested transactions by default - " +  
                    "specify 'nestedTransactionAllowed' property with value 'true'");  
        }  
        if (debugEnabled) {  
            logger.debug("Creating nested transaction with name [" + definition.getName() + "]");  
        }  
        if (useSavepointForNestedTransaction()) {  
            // Create savepoint within existing Spring-managed transaction,  
            // through the SavepointManager API implemented by TransactionStatus.  
            // Usually uses JDBC 3.0 savepoints. Never activates Spring synchronization.  
            DefaultTransactionStatus status =  
                    newTransactionStatus(definition, transaction, false, false, debugEnabled, null);  
            status.createAndHoldSavepoint();  
            return status;  
        }  
        else {  
            // Nested transaction through nested begin and commit/rollback calls.  
            // Usually only for JTA: Spring synchronization might get activated here  
            // in case of a pre-existing JTA transaction.  
            doBegin(transaction, definition);  
            boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);  
            return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);  
        }  
    }  
}

一目瞭然 

1. 咱們要設置 transactionManager 的 nestedTransactionAllowed 屬性爲 true, 注意, 此屬性默認爲 false!!! 

再看 AbstractTransactionStatus#createAndHoldSavepoint() 方法 
 

Java代碼

/** 
 * Create a savepoint and hold it for the transaction. 
 * @throws org.springframework.transaction.NestedTransactionNotSupportedException 
 * if the underlying transaction does not support savepoints 
 */  
public void createAndHoldSavepoint() throws TransactionException {  
    setSavepoint(getSavepointManager().createSavepoint());  
}

能夠看到 Savepoint 是 SavepointManager.createSavepoint 實現的, 再看 SavepointManager 的層次結構, 發現    其 Template 實現是 JdbcTransactionObjectSupport, 經常使用的 DatasourceTransactionManager, HibernateTransactionManager   中的 TransactonObject 都是它的子類 :  dbcTransactionObjectSupport 告訴咱們必需要知足兩個條件才能 createSavepoint :     2. java.sql.Savepoint 必須存在, 即 jdk 版本要 1.4+  3. Connection.getMetaData().supportsSavepoints() 必須爲 true, 即 jdbc drive 必須支持 JDBC 3.0  確保以上條件都知足後, 你就能夠嘗試使用 PROPAGATION_NESTED 了. (全文完) 

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程