導(dǎo)讀：
本來打算自己寫一篇的文章談?wù)勥@個(gè)問題，后來一搜索看到王政兄的這篇大做，寫的比較清晰透徹，就打消了自己寫一篇的想法，現(xiàn)轉(zhuǎn)載于此給朋友沒參考．
　　解惑 spring 嵌套事務(wù)
關(guān)鍵字: Spring ? ????
　　解惑 spring 嵌套事務(wù)
　　/**
　　* @author 王政
　　* @date 2006-11-24
　　* @note 轉(zhuǎn)載請注明出處
　　*/
　　在所有使用 spring 的應(yīng)用中, 聲明式事務(wù)管理可能是使用率最高的功能了, 但是, 從我觀察到的情況看,
　　絕大多數(shù)人并不能深刻理解事務(wù)聲明中不同事務(wù)傳播屬性配置的的含義, 讓我們來看一下 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??
　　我們可以看到, 在 spring 中一共定義了六種事務(wù)傳播屬性, 如果你覺得看起來不夠直觀, 那么我來轉(zhuǎn)貼一個(gè)滿大街都有的翻譯
　　引用
　　PROPAGATION_REQUIRED -- 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就新建一個(gè)事務(wù)。這是最常見的選擇。
　　PROPAGATION_SUPPORTS -- 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就以非事務(wù)方式執(zhí)行。
　　PROPAGATION_MANDATORY -- 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就拋出異常。
　　PROPAGATION_REQUIRES_NEW -- 新建事務(wù)，如果當(dāng)前存在事務(wù)，把當(dāng)前事務(wù)掛起。
　　PROPAGATION_NOT_SUPPORTED -- 以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。
　　PROPAGATION_NEVER -- 以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。
　　PROPAGATION_NESTED -- 如果當(dāng)前存在事務(wù)，則在嵌套事務(wù)內(nèi)執(zhí)行。如果當(dāng)前沒有事務(wù)，則進(jìn)行與PROPAGATION_REQUIRED類似的操作。
　　前六個(gè)策略類似于EJB CMT，第七個(gè)（PROPAGATION_NESTED）是Spring所提供的一個(gè)特殊變量。
　　它要求事務(wù)管理器或者使用JDBC 3.0 Savepoint API提供嵌套事務(wù)行為（如Spring的DataSourceTransactionManager）
　　在我所見過的誤解中, 最常見的是下面這種:
　　引用
　　假如有兩個(gè)業(yè)務(wù)接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一個(gè)方法實(shí)現(xiàn)如下
　　/**
　　* 事務(wù)屬性配置為 PROPAGATION_REQUIRED
　　*/
　　void methodA() {
　　// 調(diào)用 ServiceB 的方法
　　ServiceB.methodB();
　　}
　　那么如果 ServiceB 的 methodB 如果配置了事務(wù), 就必須配置為 PROPAGATION_NESTED
　　這種想法可能害了不少人, 認(rèn)為 Service 之間應(yīng)該避免互相調(diào)用, 其實(shí)根本不用擔(dān)心這點(diǎn)，PROPAGATION_REQUIRED 已經(jīng)說得很明白,
　　如果當(dāng)前線程中已經(jīng)存在事務(wù), 方法調(diào)用會加入此事務(wù), 果當(dāng)前沒有事務(wù)，就新建一個(gè)事務(wù), 所以 ServiceB#methodB() 的事務(wù)只要遵循最普通的規(guī)則配置為 PROPAGATION_REQUIRED 即可, 如果 ServiceB#methodB (我們稱之為內(nèi)部事務(wù), 為下文打下基礎(chǔ)) 拋了異常, 那么 ServiceA#methodA(我們稱之為外部事務(wù)) 如果沒有特殊配置此異常時(shí)事務(wù)提交 (即 +MyCheckedException的用法), 那么整個(gè)事務(wù)是一定要 rollback 的, 什么 Service 只能調(diào) Dao 之類的言論純屬無稽之談, spring 只負(fù)責(zé)配置了事務(wù)屬性方法的攔截, 它怎么知道你這個(gè)方法是在 Service 還是 Dao 里 ?
　　說了這么半天, 那到底什么是真正的事務(wù)嵌套呢, 解釋之前我們來看一下 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.
　　也就是說, 最容易弄混淆的其實(shí)是 PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED, 那么這兩種方式又有何區(qū)別呢? 我簡單的翻譯一下 Juergen Hoeller 的話 :
　　PROPAGATION_REQUIRES_NEW 啟動一個(gè)新的, 不依賴于環(huán)境的 "內(nèi)部" 事務(wù). 這個(gè)事務(wù)將被完全 commited 或 rolled back 而不依賴于外部事務(wù), 它擁有自己的隔離范圍, 自己的鎖, 等等. 當(dāng)內(nèi)部事務(wù)開始執(zhí)行時(shí), 外部事務(wù)將被掛起, 內(nèi)務(wù)事務(wù)結(jié)束時(shí), 外部事務(wù)將繼續(xù)執(zhí)行.
　　另一方面, PROPAGATION_NESTED 開始一個(gè) "嵌套的" 事務(wù), 它是已經(jīng)存在事務(wù)的一個(gè)真正的子事務(wù). 潛套事務(wù)開始執(zhí)行時(shí), 它將取得一個(gè) savepoint. 如果這個(gè)嵌套事務(wù)失敗, 我們將回滾到此 savepoint. 潛套事務(wù)是外部事務(wù)的一部分, 只有外部事務(wù)結(jié)束后它才會被提交.
　　由此可見, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大區(qū)別在于, PROPAGATION_REQUIRES_NEW 完全是一個(gè)新的事務(wù), 而 PROPAGATION_NESTED 則是外部事務(wù)的子事務(wù), 如果外部事務(wù) commit, 潛套事務(wù)也會被 commit, 這個(gè)規(guī)則同樣適用于 roll back.
　　那么外部事務(wù)如何利用嵌套事務(wù)的 savepoint 特性呢, 我們用代碼來說話
　　代碼
　　ServiceA?{ ??

　　/** ?
　　*?事務(wù)屬性配置為?PROPAGATION_REQUIRED ?
　　*/??
　　void?methodA()?{ ??
　　ServiceB.methodB(); ??
　　} ??

　　} ??

　　ServiceB?{ ??

　　/** ?
　　*?事務(wù)屬性配置為?PROPAGATION_REQUIRES_NEW ?
　　*/? ??
　　void?methodB()?{ ??
　　} ??

　　}??? ??
　　這種情況下, 因?yàn)?ServiceB#methodB 的事務(wù)屬性為 PROPAGATION_REQUIRES_NEW, 所以兩者不會發(fā)生任何關(guān)系, ServiceA#methodA 和 ServiceB#methodB 不會因?yàn)閷Ψ降膱?zhí)行情況而影響事務(wù)的結(jié)果, 因?yàn)樗鼈兏揪褪莾蓚€(gè)事務(wù), 在 ServiceB#methodB 執(zhí)行時(shí) ServiceA#methodA 的事務(wù)已經(jīng)掛起了 (關(guān)于事務(wù)掛起的內(nèi)容已經(jīng)超出了本文的討論范圍, 有時(shí)間我會再寫一些掛起的文章) .
　　那么 PROPAGATION_NESTED 又是怎么回事呢? 繼續(xù)看代碼
　　代碼
　　ServiceA?{ ??

　　/** ?
　　*?事務(wù)屬性配置為?PROPAGATION_REQUIRED ?
　　*/??
　　void?methodA()?{ ??
　　ServiceB.methodB(); ??
　　} ??

　　} ??

　　ServiceB?{ ??

　　/** ?
　　*?事務(wù)屬性配置為?PROPAGATION_NESTED ?
　　*/? ??
　　void?methodB()?{ ??
　　} ??

　　}??? ??
　　現(xiàn)在的情況就變得比較復(fù)雜了, ServiceB#methodB 的事務(wù)屬性被配置為 PROPAGATION_NESTED, 此時(shí)兩者之間又將如何協(xié)作呢? 從 Juergen Hoeller 的原話中我們可以找到答案, ServiceB#methodB 如果 rollback, 那么內(nèi)部事務(wù)(即 ServiceB#methodB) 將回滾到它執(zhí)行前的 SavePoint(注意, 這是本文中第一次提到它, 潛套事務(wù)中最核心的概念), 而外部事務(wù)(即 ServiceA#methodA) 可以有以下兩種處理方式:
　　1. 改寫 ServiceA 如下
　　代碼
　　ServiceA?{ ??

　　/** ?
　　*?事務(wù)屬性配置為?PROPAGATION_REQUIRED ?
　　*/??
　　void?methodA()?{ ??
　　try?{ ??
　　ServiceB.methodB(); ??
　　}?catch?(SomeException)?{ ??
　　//?執(zhí)行其他業(yè)務(wù),?如?ServiceC.methodC(); ??
　　} ??
　　} ??

　　} ??

　　這種方式也是潛套事務(wù)最有價(jià)值的地方, 它起到了分支執(zhí)行的效果, 如果 ServiceB.methodB 失敗, 那么執(zhí)行 ServiceC.methodC(), 而 ServiceB.methodB 已經(jīng)回滾到它執(zhí)行之前的 SavePoint, 所以不會產(chǎn)生臟數(shù)據(jù)(相當(dāng)于此方法從未執(zhí)行過), 這種特性可以用在某些特殊的業(yè)務(wù)中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都沒有辦法做到這一點(diǎn). (題外話 : 看到這種代碼, 似乎似曾相識, 想起了 prototype.js 中的 Try 函數(shù) )
　　2. 代碼不做任何修改, 那么如果內(nèi)部事務(wù)(即 ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滾到它執(zhí)行之前的 SavePoint(在任何情況下都會如此),
　　外部事務(wù)(即 ServiceA#methodA) 將根據(jù)具體的配置決定自己是 commit 還是 rollback (+MyCheckedException).
　　上面大致講述了潛套事務(wù)的使用場景, 下面我們來看如何在 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. 我們要設(shè)置 transactionManager 的 nestedTransactionAllowed 屬性為 true, 注意, 此屬性默認(rèn)為 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 實(shí)現(xiàn)的, 再看 SavepointManager 的層次結(jié)構(gòu), 發(fā)現(xiàn)
　　其 Template 實(shí)現(xiàn)是 JdbcTransactionObjectSupport, 常用的 DatasourceTransactionManager, HibernateTransactionManager
　　中的 TransactonObject 都是它的子類 :


　　JdbcTransactionObjectSupport 告訴我們必須要滿足兩個(gè)條件才能 createSavepoint :
　　2. java.sql.Savepoint 必須存在, 即 jdk 版本要 1.4+
　　3. Connection.getMetaData().supportsSavepoints() 必須為 true, 即 jdbc drive 必須支持 JDBC 3.0
　　確保以上條件都滿足后, 你就可以嘗試使用 PROPAGATION_NESTED 了. (全文完)

本文轉(zhuǎn)自
http://former6.spaces.live.com/blog/cns!33af086ef96ea42!114.entry

spring 聲明式事務(wù)各種配置解析