目前，似乎很少有支持嵌套事務(wù)的中間件，但嵌套事務(wù)確實(shí)存在。
假定有Method A, Method B, Method C
A 調(diào)用 B，C
ServiceHost?{????
????????
????/**???
?????*?事務(wù)屬性配置為?PROPAGATION_REQUIRED???
?????*/???
????void?invoke()?{????
??????try{
???????????ServiceA.invoke()
??????}?catch?(Bussiness.A.Exception)?{?
?????????? abort()
??????}
????????try?{????
????????????ServiceB.invoke();????
????????}?catch?(Bussiness.B.Exception)?{????
????????????ServiceC.invoke();
????????}?catch?(Bussiness.C.Exception)?{????
????????????ServiceD.invoke();
????????} catch?(Bussiness.D.Exception)?{?
?????????? abort()
??????}
??
????????try{
???????????ServiceE.invoke()
????????}?catch?(Bussiness.E.Exception)?{?
???????????ServiceF.invoke()
????????}catch?(Bussiness.F.Exception)?{?
?????????? abort()
??????}
????}????
???
}?
ServiceA?{????
????????
????/**???
?????*?事務(wù)屬性配置為?PROPAGATION_NESTED,?
?????×?即該事務(wù)需要被嵌套???
?????*/?????
????void?methodA()?{????
????}????
????????
}
ServiceA, ServiceB, ServiceC, ServiceD, ServiceE, ServiceF都配置為PROPAGATION_NESTED
通過(guò)這樣的嵌套規(guī)約，我們可以滿(mǎn)足業(yè)務(wù)完整性的需求，一個(gè)ServiceParent?業(yè)務(wù)，只允許出現(xiàn)A-B-E , A-B-F, A-C-E, A-C-F, A-D-E，A-D-F的組合，其他組合，如A-B-C, A-E, B-F都是不允許的。
?
術(shù)語(yǔ)上，ServiceA, B, C, D, E, F的事務(wù)均是ServiceParent事務(wù)的子事務(wù)，現(xiàn)在，是ServiceParent嵌套ServiceA-F，且嵌套事務(wù)的幾個(gè)特性如下：
1，? 假定子事務(wù)(ServiceA-F)處于活動(dòng)狀態(tài)(active)，則parent事務(wù)(ServiceParent)不能執(zhí)行任何其他操作，父事務(wù)只能commit事務(wù)，abort事務(wù)以及創(chuàng)建更多其它子事務(wù)。
2，? 若子事務(wù)(ServiceA)被提交了，此時(shí)父事務(wù)則能夠看到子事務(wù)做出的任何修改，這些修改，對(duì)其他子事務(wù)來(lái)說(shuō)是隱藏的，直到父事務(wù)提交為止。
3，? 同樣地，如果被嵌套的事務(wù)ServiceA被回滾了，則它也不會(huì)對(duì)父事務(wù)有任何影響，且父事務(wù)servieParent也不會(huì)看到ServiceA曾經(jīng)修改過(guò)的數(shù)據(jù)。
4，? 最終父事務(wù)提交、回滾才會(huì)決定到子事務(wù)的提交、回滾。表達(dá)的形象點(diǎn)，若ServiceA“提交”后，ServiceParent卻因?yàn)?/span>Service B/C/D都無(wú)法成功執(zhí)行，ServiceA會(huì)回滾。這種做法依賴(lài)于JDBC 3.0 SavePoint技術(shù)。
5，? 嵌套子事務(wù)提交后，它對(duì)DB的鎖其實(shí)并沒(méi)有釋放，這些鎖的控制權(quán)被轉(zhuǎn)交給父事務(wù)，直到父事務(wù)提交（或回滾）后，鎖才會(huì)真正釋放
6，? 目前，嵌套的深度不收控制，也就是，我們可對(duì)method進(jìn)行以深度嵌套。
?
?
???????????
??????現(xiàn)在，我們略略了解一下JDBC SavePoint技術(shù)，它給予了我們這樣的能力，在一個(gè)事務(wù)里面，我們能夠?qū)⒁呀?jīng)提交的事務(wù)狀態(tài)，恢復(fù)到一個(gè)事務(wù)commit以前的任意定點(diǎn)(這個(gè)點(diǎn)就是SavePoint)。
??????????? 舉個(gè)例子，假設(shè)我們面臨這樣一種情況，methodA是運(yùn)算代價(jià)非常大的事務(wù)操作，methodB, methodC都是輕量級(jí)的事務(wù)，我們需要執(zhí)行這樣一個(gè)事務(wù)Tx={methodA->methodB->methodC}。
?????????? 沒(méi)有SavePoint之前，如果methodA執(zhí)行成功，但是恰恰methodB失敗了，那么methodA所有成果必須回滾，methodC也別想執(zhí)行了，因?yàn)?/span>methodA、methodB、methodC都在同一個(gè)Tx事務(wù)中；JDBC3.0的SavePoint技術(shù)為我們提供了一個(gè)無(wú)需回滾MethodA的折衷辦法，可以讓我們?cè)诒Ａ?/span>methodA的成果的同時(shí)，僅僅回滾methodB，然后繼續(xù)執(zhí)行methodC。
????? 回滾到SavePoint的代碼類(lèi)似于：
Statement?stmt?=?conn.createStatement();
int?rows?=?stmt.executeUpdate("INSERT?INTO?TAB1?(COL1)?VALUES?"?+
"(’FIRST’)");
//?set?savepoint
Savepoint?svpt1?=?conn.setSavepoint("SAVEPOINT_1");
rows?=?stmt.executeUpdate("INSERT?INTO?TAB1?(COL1)?"?+
"VALUES?(’SECOND’)");
conn.rollback(svpt1);
conn.commit();