2. 程式人生 > >解惑 spring 巢狀事務 - Spring

解惑 spring 巢狀事務 - Spring

阿新 • • 發佈：2018-11-03

解惑 spring 巢狀事務

在所有使用 spring 的應用中, 宣告式事務管理可能是使用率最高的功能了, 但是, 從我觀察到的情況看,
絕大多數人並不能深刻理解事務宣告中不同事務傳播屬性配置的的含義, 讓我們來看一下 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.
 * <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 中一共定義了六種事務傳播屬性, 如果你覺得看起來不夠直觀, 那麼我來轉貼一個滿大街都有的翻譯

引用

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）

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

引用

假如有兩個業務介面 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 特性呢, 我們用程式碼來說話 


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 又是怎麼回事呢? 繼續看程式碼

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) 可以有以下兩種處理方式:

  1. 改寫 ServiceA 如下

    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 函式 )

  1. 程式碼不做任何修改, 那麼如果內部事務(即 ServiceB#methodB) rollback, 那麼首先 ServiceB.methodB 回滾到它執行之前的 SavePoint(在任何情況下都會如此),
    外部事務(即 ServiceA#methodA) 將根據具體的配置決定自己是 commit 還是 rollback (+MyCheckedException).

上面大致講述了潛套事務的使用場景, 下面我們來看如何在 spring 中使用 PROPAGATION_NESTED, 首先來看 AbstractPlatformTransactionManager

/**
 * 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() 方法

/**
 * 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 都是它的子類 :

JdbcTransactionObjectSupport 告訴我們必須要滿足兩個條件才能 createSavepoint :

  1. java.sql.Savepoint 必須存在, 即 jdk 版本要 1.4+
  2. Connection.getMetaData().supportsSavepoints() 必須為 true, 即 jdbc drive 必須支援 JDBC 3.0

確保以上條件都滿足後, 你就可以嘗試使用 PROPAGATION_NESTED 了. (全文完)

相關推薦

解惑 spring 巢狀事務 - Spring

解惑 spring 巢狀事務 在所有使用 spring 的應用中, 宣告式事務管理可能是使用率最高的功能了, 但是, 從我觀察到的情況看, 絕大多數人並不能深刻理解事務宣告中不同事務傳播屬性配置的的含義, 讓我們來看一下 TransactionDefinition 介面中的定義 /*

MYSQL 巢狀事務（SAVEPOINT) 與Spring 事務傳播

摘要 savepoint 關鍵字可以實現巢狀事務。結合savepoint關鍵字，更方便理解spring的事務傳播。 事務巢狀 初始

spring巢狀事物

一、事務傳播屬性 REQUIRED：業務方法需要在一個事務中執行。如果方法執行時，已經處在一個事務中，那麼這個時候就會加入到該事務中，如果當前沒有事務環境的話，就會為自己建立一個新的事務。預設情況下，業務方法的事務傳播屬性就是REQUIRED。在應用開發中，8

sql server中巢狀事務*

轉自 https://www.cnblogs.com/guanjie20/archive/2013/02/17/2914488.html 我們在寫事務時經常遇到的問題如下： 訊息 266，級別 16，狀態 2，過程 sp1，第 0 行 EXECUTE 後的事務計數指示&nb

laravel 巢狀事務

什麼是巢狀事務? 一般情況下我們都是一個 begin, 一個 commit 或 rollBack, 但是有可能我們有種場景需要 begin 然後在事務裡面再開一個事務, 這就是巢狀事務. MySQL 巢狀事務支援 MySQL 裡面有個 savepoint 關鍵字, 可以模擬巢狀事務,

巢狀事務總結

最近線上發生了一起故障，是關於巢狀事務未回滾的問題，這裡記錄一下。 發生故障的場景是：  主方法parent（）裡調child（）方法，當child（）丟擲異常時，parent（）和child（）均未回滾。背景先介紹到這裡，你可以先想想為什麼沒回滾，下面由淺入深講解。

巢狀事務，預設事務傳播機制測試總結PROPAGATION_REQUIRED

這裡應用的是預設事務傳播機制而且是基於註解形式的。 1.新增@Transactional註釋即可進行事務異常回滾，如果需要try{}catch必須try{}catch後丟擲異常否則不會回滾 2.巢狀事務，內部異常，內外都回滾 3.巢狀事務，外部異常，內外都回滾 4.巢狀事務，外部異常try{

軟體事務記憶體導論(五)建立巢狀事務

宣告：本文是《Java虛擬機器併發程式設計》的第六章，感謝華章出版社授權併發程式設計網站釋出此文，禁止以任何形式轉載此文。 1.1    建立巢狀事務 在之前的示例中，每個用到事務的方法都是各自在其內部單獨建立事務，並且事務所涉及的變動也都是各自獨立提交的。但如果我們想要將多個方法裡的事務調整

MySQL的巢狀事務實現

一、問題起源 在MySQL的官方文件中有明確的說明不支援巢狀事務： Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when

SqlServer中巢狀事務使用--事務計數指示 BEGIN 和 COMMIT 語句的數目不匹配 －－根本問題

問題： 1. System.Data.SqlClient.SqlException (0x80131904): EXECUTE 後的事務計數指示 BEGIN 和 COMMIT 語句的數目不匹配。上一計數 = 1，當前計數 = 0。 2. EXECUTE 後的事務計數指示 B

巢狀事務的回滾

巢狀事務和事務儲存點的錯誤處理 對於巢狀事務。 1.外部起事務，內部起事務，內外都有Try Catch 內部出錯:如果內部事務出錯，內部和外部事物全部回滾，外部回滾之前的操作全部不存在，但是之後的操作繼續執行。 外部出錯:如果外部事物出錯，內部和外部事物全部回滾，外部

[SQL Server]巢狀事務與分散式事務

 Sql Server支援巢狀事務：也就是說在前一事務未完成之前可啟動一個新的事務，只有在外層的Commit Tran語句才會導致資料庫的永久更改。請嘗試執行以下語句：BEGIN  TRAN  tr0       BEGIN TRAN tr1        ROLLBACK

Spring宣告式事務管理及事務巢狀

一>  事務配置 Spring動態代理的一個重要特徵是，它是針對介面的，所以我們的dao要通過動態代理來讓spring接管事務，就必須在dao前面抽象出一個介面，當然如果沒有這樣的介面，那麼spring會使用CGLIB來解決問題。     一般地，使用Spri

Spring Aop巢狀呼叫時沒有生效

轉載自：https://blog.csdn.net/hong10086/article/details/78424481   Spring AOP在同一個類裡自身方法相互呼叫時是無法攔截的。比如在一個 Service 類的 doSomething1() 方法中通過doSomething2

Spring Web Flow 入門demo（三）巢狀流程與業務結合 附原始碼

上篇部落格我們說Spring web Flow與業務結合的方式主要有三種，下面我們主要介紹一下第三種的應用方式3，執行到<action-state> 元素SpringWeb Flow 中的這

spring aop 無法在內部巢狀的方法上生效

1，問題 例子： public void method1(){ ......... method2(); ........... } public void method2(){ ............... .......

atitit.spring hibernate的事務機制 spring不能保存對象的解決

pda 程序 oca roman 配置 轉載 post 本地事務 對象 atitit.spring hibernate的事務機制 spring不能保存對象的解決 sessionFactory.openSession() 不能。。log黑頭馬sql語言..

spring如何控制事務

切面 進行 具體類 控制 編程 面向切面 程序 管理 最大的 Spring 的事務，可以說是 Spring AOP 的一種實現。 AOP面向切面編程，即在不修改源代碼的情況下，對原有功能進行擴展，通過代理類來對具體類進行操作。 spring是一個容器，通過sp

Spring 實現部分事務回滾

light back true prop 回滾 sage .class lba aaa 例如有業務需求，在catch異常後，catch塊內把異常的信息存入到數據庫，而catch外的數據全部回滾 try { ....... aaaService.save();

spring、mybatis事務配置和控制

數據庫 one ons str size 連接池 action b2c drive springmybatis.xml <beans xmlns="http://www.springframework.org/schema/beans" xmlns:x