事務(wù)傳播行為

1、事務(wù)傳播行為文章一：我們都知道事務(wù)的概念，那么事務(wù)的傳播特性是什么呢？ （此處著重介紹傳播特性的概念， 關(guān)于傳播特性的 相關(guān)配置就不介紹了，可以查看 spring 的官方文檔 ） 在我們 用 SSH 開發(fā)項目的時候， 我們一般都是將事務(wù)設(shè)置在 Service層 那么當(dāng)我們調(diào)用 Service 層的一個方法的時候它能夠保證 我們的這個方法中執(zhí)行的所有的對數(shù)據(jù)庫的更新操作保持 在一個事務(wù)中，在事務(wù)層里面調(diào)用的這些方法要么全部成Dao 層功，要么全部失敗。 那么事務(wù)的傳播特性也是從這里說起的。如果你在你的 Service 層的這個方法中，除了調(diào)用了 的方法之外，還調(diào)用了本類的其他的 Service

2、方法，那么在 調(diào)用其他的 Service 方法的時候，這個事務(wù)是怎么規(guī)定的呢， 我必須保證我在我方法里掉用的這個方法與我本身的方法 處在同一個事務(wù)中，否則如果保證事物的一致性。事務(wù)的傳 播特性就是解決這個問題的， “事務(wù)是會傳播的”在 Spring中有針對傳播特性的多種配置我們大多數(shù)情況下只用其 的一種 :PROPGATION_REQUIRED ：這個配置項的意思是說 當(dāng)我調(diào)用 service 層的方法的時候開啟一個事務(wù) （具體調(diào)用那層的方法開始創(chuàng)建事務(wù)，要看你的aop的配置）,那么在調(diào)用這個 service 層里面的其他的方法的時候 ,如果當(dāng)前方法產(chǎn)生了事務(wù)就用當(dāng)前方法產(chǎn)生的事務(wù)，否則就創(chuàng)建

3、一個新的事務(wù)。這個工作使由 Spring 來幫助我們完成的。 以前沒有Spring 幫助我們完成事務(wù)的時候我們必須自己手動的控制事務(wù)，例如當(dāng)我們項目中僅僅使用hibernate，而沒有集成進(jìn)spring 的時候，我們在一個 service 層中調(diào)用其他的業(yè)務(wù)邏輯方法，為了保證事物必須也要把當(dāng)前的hibernate session 傳遞session到下一個方法中，或者采用 ThreadLocal 的方法，將 傳遞給下一個方法，其實都是一個目的?，F(xiàn)在這個工作由spring 來幫助我們完成，就可以讓我們更加的專注于我們的 業(yè)務(wù)邏輯。而不用去關(guān)心事務(wù)的問題。 默認(rèn)情況下當(dāng)發(fā)生RuntimeExcep

4、tion 的情況下，事務(wù)才會回滾，所以要注意如果你在程序發(fā)生錯誤的情況下，有自己的異常處理機(jī) 制定義自己的 Exception ，必須從 RuntimeException 類繼承 這 樣事務(wù)才會回滾！Propagation ： key文章二： 事務(wù)的傳播行為和隔離級別 transaction behavior and中事務(wù)的定義：isolated levelSpring屬性確定代理應(yīng)該給哪個方法增加事務(wù)行為。這樣的屬性最 重要的部份是傳播行為。有以下選項可供使用：PROPAGATION_REQUIRED- 支持當(dāng)前事務(wù)，如果當(dāng)前沒有 事務(wù)，就新建一個事務(wù)。這是最常見的選擇。PROPAGATIO

5、N_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ù)，則拋出異常。 很多人看到事務(wù)的傳播行為屬性都不 甚了解，我昨晚看了 j2ee without ejb 的時候，看到這里也不 了解，甚至重新翻起

6、數(shù)據(jù)庫系統(tǒng)的教材書，但是也沒有找到 對這個的分析。今天搜索，找到一篇極好的分析文章，雖然 這篇文章是重點分析 PROPAGATION_REQUIRED 和PROPAGATION_REQUIRED_NESTED 的解惑 spring 嵌套事務(wù) *TransactionDefinition 接口定義*int PROPAGATION_REQUIRED= 0;int PROPAGATION_SUPPORTS = 1;int PROPAGATION_MANDATORY = 2;intPROPAGATION_REQUIRES_NEW = 3;intPROPAGATION_NOT_SUPPORTED = 4

7、;int PROPAGATION_NEVER = 5;intPROPAGATION_NESTED = 6;*在這篇文章里，他用兩個嵌套的例子輔助分析，我這里直接引用了。*sample*ServiceA void methodA()ServiceB.methodB();ServiceB void methodB()*們這里一個個分析吧 1： PROPAGATION_REQUIRED加入當(dāng)前正要執(zhí)行的事務(wù)不在另外一個事務(wù)里，那么就起一個新的事務(wù)比如說， ServiceB.methodB 的事務(wù)級別定義為PROPAGATION_REQUIRED, 那么由于執(zhí)行ServiceA.methodA 的時候

8、，ServiceA.methodA已經(jīng)起了事務(wù)，這時調(diào)用 ServiceB.methodB ， ServiceB.methodB看到自己已經(jīng)運(yùn)行在 ServiceA.methodA 的事務(wù)內(nèi)部， 就不再 起新的事務(wù)。 而假如 ServiceA.methodA 運(yùn)行的時候發(fā)現(xiàn)自己 沒有在事務(wù)中，他就會為自己分配一個事務(wù)。這樣，在ServiceA.methodA 或者在 ServiceB.methodB 內(nèi)的任何地方出 現(xiàn)異常，事務(wù)都會被回滾。即使 ServiceB.methodB 的事務(wù)已 經(jīng)被提交，但是 ServiceA.methodA 在接下來 fail 要回滾，ServiceB.metho

9、dB 也要回滾 2：PROPAGATION_SUPPORTS 如果當(dāng)前在事務(wù)中，即以事務(wù)的形式運(yùn)行，如果當(dāng)前不再一個事務(wù)中，那么就以非事務(wù)的形式運(yùn)行這就跟平常用的普通非事務(wù)的代碼只有一點點區(qū)別了。不理這個，因為我也沒有覺得有什么區(qū)別3：PROPAGATION_MANDATORY 必須在一個事務(wù)中運(yùn)行。也 就是說， 他只能被一個父事務(wù)調(diào)用。 否則，他就要拋出異常。4： PROPAGATION_REQUIRES_NEW 這個就比較繞口了。比如我們設(shè)計ServiceA.methodA 的事務(wù)級別為PROPAGATION_REQUIRED ，ServiceB.methodB 的事務(wù)級別 為 PROPA

10、GATION_REQUIRES_NEW ，那么當(dāng)執(zhí)行到ServiceB.methodB 的時候， ServiceA.methodA 所在的事務(wù)就 會掛起， ServiceB.methodB 會起一個新的事務(wù)，等待ServiceB.methodB 的事務(wù)完成以后，他才繼續(xù)執(zhí)行。他與PROPAGATION_REQUIRED 的事務(wù)區(qū)別在于事務(wù)的回滾程 度了。因為 ServiceB.methodB 是新起一個事務(wù)，那么就是存 在兩個不同的事務(wù)。如果 ServiceB.methodB 已經(jīng)提交，那么ServiceA.methodA 失敗回滾， ServiceB.methodB 是不會回滾 的。如果 S

11、erviceB.methodB 失敗回滾，如果他拋出的異常被ServiceA.methodA 捕獲， ServiceA.methodA 事務(wù)仍然可能提 交。 5： PROPAGATION_NOT_SUPPORTED 當(dāng)前不支持 事務(wù)。比如 ServiceA.methodA 的事務(wù)級別是PROPAGATION_REQUIRED ，而 ServiceB.methodB 的事務(wù) 級別是 PROPAGATION_NOT_SUPPORTED ，那么當(dāng)執(zhí)行到ServiceB.methodB 時， ServiceA.methodA 的事務(wù)掛起，而他 以非事務(wù)的狀態(tài)運(yùn)行完，再繼續(xù) ServiceA.metho

12、dA 的事務(wù)。6： PROPAGATION_NEVER不能在事務(wù)中運(yùn)行。假設(shè)ServiceA.methodA 的事務(wù)級別是PROPAGATION_REQUIRED ，而 ServiceB.methodB 的事務(wù)級別是 PROPAGATION_NEVER，那么 ServiceB.methodB就要拋出異常了。7： PROPAGATION_NESTED 理解Nested 的關(guān)鍵是save po int。他與PROPAGATIONREQUIRES_NEW的區(qū)別是，PROPAGATION_REQUIRES_NEW另起一個事務(wù)， 將會與他的父事務(wù)相互獨立，而 Nested 的事務(wù)和他的父事務(wù)是相依 的，

13、他的提交是要等和他的父事務(wù)一塊提交的。也就是說， 如果父事務(wù)最后回滾， 他也要回滾的。而Nested事務(wù)的好處 是他有一個 savepoint。*ServiceA/savepoint/PROPAGATION_NESTED(SomeException) void methodA() ServiceB.methodB();級別 catch/執(zhí)行其他業(yè)務(wù) , 如tryServiceC.methodC();也就是*說 ServiceB.methodB 失敗回滾， 那么 ServiceA.methodA 也會 回滾到save point點上，ServiceA.methodA 可以選擇另外一個 分支，比如

14、 ServiceC.methodC ,繼續(xù)執(zhí)行，來嘗試完成自己的事務(wù)。但是這個事務(wù)并沒有在EJB標(biāo)準(zhǔn)中定義。二、Isolation2、 REPEATABLE READLevel（事務(wù)隔離等級）:1、Serializable:最嚴(yán)格的級別，事務(wù)串 行執(zhí)行，資源消耗最大； 2、 REPEATABLE READ ：保證了個事務(wù)不會修改已經(jīng)由另一個事務(wù)讀取但未提交（回滾） 的數(shù)據(jù)。避免了“臟讀取”和“不可重復(fù)讀取”的情況，但是帶來了更多的性能損失。3、 READ COMMITTED: 大多數(shù)主流數(shù)據(jù)庫的默認(rèn)事務(wù)等級，保證了一個事務(wù)不會讀到另個并行事務(wù)已修改但未提交的數(shù)據(jù)，避免了“臟讀取”。該級別適用于

15、大多數(shù)系統(tǒng)。4、Read Uncommitted :保證了讀取 過程中不會讀取到非法數(shù)據(jù)。隔離級別在于處理多事務(wù)的并 發(fā)問題。我們知道并行可以提高數(shù)據(jù)庫的吞吐量和效率，但 是并不是所有的并發(fā)事務(wù)都可以并發(fā)運(yùn)行，這需要查看數(shù)據(jù) 庫教材的可串行化條件判斷了。這里就不闡述。我們首先說并發(fā)中可能發(fā)生的 3中不討人喜歡的事情 1:Dirty reads-讀臟數(shù)據(jù)。也就是說，比如事務(wù) A 的未提交（還依然緩存） 的數(shù)據(jù)被事務(wù) B 讀走， 如果事務(wù) A 失敗回滾， 會導(dǎo)致事務(wù) B所讀取的的數(shù)據(jù)是錯誤的。 2:non-repeatable reads-數(shù)據(jù)不可重復(fù)讀。比如事務(wù) A中兩處讀取數(shù)據(jù)-total-的

16、值。在第讀的時候， total 是 100，然后事務(wù) B 就把 total 的數(shù)據(jù)改成200，事務(wù) A 再讀一次，結(jié)果就發(fā)現(xiàn)， total 竟然就變成 200了，造成事務(wù) A 數(shù)據(jù)混亂。 3:phantom reads-幻象讀數(shù)據(jù)，這個和non-repeatable reads相似，也是同一個事務(wù)中多次讀不一致的問題。但是 non-repeatable reads 的不一致是因 為他所要取的數(shù)據(jù)集被改變了（比如 total 的數(shù)據(jù)），但是Select account.idphantom reads所要讀的數(shù)據(jù)的不一致卻不是他所要讀的數(shù)據(jù)集改變，而是他的條件數(shù)據(jù)集改變。比如where ="ppgogo*", 第一次讀去了 6 個符合條件 的id，第二次讀取的時候，由于事務(wù) b把一個帳號的名字由"dd"改成"ppgogol"，結(jié)果取出來了 7個數(shù)據(jù)。Dirty readsnon-repeatable readsphantom readsSerializable不會不會不會 REPEATABLEREAD不會不會會 READ COMMITTED不會會 Read Unc