Spring 聲明式事務(wù)讓我們從復(fù)雜的事務(wù)處理中得到解脫。使得我們再也無需要去處理獲得連接、關(guān)閉連接、事務(wù)提交和回滾等這些操作。再也無需要我們在與事務(wù)相關(guān)的方法中處理大量的 try… catch … finally 代碼。 我們在使用 Spring 聲明式事務(wù)時，有一個非常重要的概念就是事務(wù)屬性。事務(wù)屬性通常由事務(wù)的傳播行為，事務(wù)的隔離級別，事務(wù)的超時值和事務(wù)只讀標(biāo)志組成。我們在進(jìn)行事務(wù)劃分時，需要進(jìn)行事務(wù)定義，也就是配置事務(wù)的屬性。
Spring 在 TransactionDefinition 接口中定義這些屬性 , 以供 PlatfromTransactionManager 使用 , PlatfromTransactionManager 是 spring 事務(wù)管理的核心接口。
l getTimeout() 方法，它返回事務(wù)必須在多少秒內(nèi)完成。
l isReadOnly() , 事務(wù)是否只讀，事務(wù)管理器能夠根據(jù)這個返回值進(jìn)行優(yōu)化，確保事務(wù)是只讀的。
l getIsolationLevel() 方法返回事務(wù)的隔離級別，事務(wù)管理器根據(jù)它來控制另外一個事務(wù)可以看到本事務(wù)內(nèi)的哪些數(shù)據(jù)。
在 TransactionDefinition 接口中定義了五個不同的事務(wù)隔離級別：
l ISOLATION_DEFAULT 這是一個 PlatfromTransactionManager 默認(rèn)的隔離級別，使用數(shù)據(jù)庫默認(rèn)的事務(wù)隔離級別 . 另外四個與 JDBC 的隔離級別相對應(yīng)
l ISOLATION_READ_UNCOMMITTED 這是事務(wù)最低的隔離級別，它充許別外一個事務(wù)可以看到這個事務(wù)未提交的數(shù)據(jù)。這種隔離級別會產(chǎn)生臟讀，不可重復(fù)讀和幻像讀。 例如 : Mary的原工資為 1000, 財務(wù)人員將 Mary 的工資改為了 8000 ，但未提交事務(wù) 與此同時， Mary正在讀取自己的工資 Mary 發(fā)現(xiàn)自己的工資變?yōu)榱?/span> 8000 ，歡天喜地！ 而財務(wù)發(fā)現(xiàn)操作有誤，而回滾了事務(wù) ,Mary 的工資又變?yōu)榱?/span> 1000. 像這樣 ,Mary 記取的工資數(shù) 8000 是一個臟數(shù)據(jù)。
l ISOLATION_READ_COMMITTED 保證一個事務(wù)修改的數(shù)據(jù)提交后才能被另外一個事務(wù)讀取。另外一個事務(wù)不能讀取該事務(wù)未提交的數(shù)據(jù)。這種事務(wù)隔離級別可以避免臟讀出現(xiàn)，但是可能會出現(xiàn)不可重復(fù)讀和幻像讀。
l ISOLATION_REPEATABLE_READ 這種事務(wù)隔離級別可以防止臟讀，不可重復(fù)讀。但是可能出現(xiàn)幻像讀。它除了保證一個事務(wù)不能讀取另一個事務(wù)未提交的數(shù)據(jù)外，還保證了避免下面的情況產(chǎn)生 ( 不可重復(fù)讀 ) 。 在事務(wù) 1 中， Mary 讀取了自己的工資為 1000, 操作并沒有完成 在事務(wù) 2 中，這時財務(wù)人員修改了 Mary 的工資為 2000, 并提交了事務(wù) . 在事務(wù) 1 中，Mary 再次讀取自己的工資時，工資變?yōu)榱?/span> 2000 在一個事務(wù)中前后兩次讀取的結(jié)果并不致，導(dǎo)致了不可重復(fù)讀。 使用 ISOLATION_REPEATABLE_READ 可以避免這種情況發(fā)生。
l ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務(wù)隔離級別。事務(wù)被處理為順序執(zhí)行。除了防止臟讀，不可重復(fù)讀外，還避免了幻像讀。 目前工資為 1000 的員工有 10人。 事務(wù) 1, 讀取所有工資為 1000 的員工。 共讀取 10 條記錄 這時另一個事務(wù)向 employee表插入了一條員工記錄，工資也為 1000 事務(wù) 1 再次讀取所有工資為 1000 的員工 共讀取到了 11 條記錄，這就產(chǎn)生了幻像讀。 ISOLATION_SERIALIZABLE 能避免這樣的情況發(fā)生。但是這樣也耗費了最大的資源。
getPropagationBehavior () 返回事務(wù)的傳播行為，由是否有一個活動的事務(wù)來決定一個事務(wù)調(diào)用。 在 TransactionDefinition 接口中定義了七個事務(wù)傳播行為：
l PROPAGATION_REQUIRED 如果存在一個事務(wù)，則支持當(dāng)前事務(wù)。如果沒有事務(wù)則開啟一個新的事務(wù)。 使用 spring 聲明式事務(wù)， spring 使用 AOP 來支持聲明式事務(wù)，會根據(jù)事務(wù)屬性，自動在方法調(diào)用之前決定是否開啟一個事務(wù)，并在方法執(zhí)行之后決定事務(wù)提交或回滾事務(wù)。 單獨調(diào)用 methodB 方法 相當(dāng)于 Spring 保證在 methodB 方法中所有的調(diào)用都獲得到一個相同的連接。在調(diào)用 methodB 時，沒有一個存在的事務(wù)，所以獲得一個新的連接，開啟了一個新的事務(wù)。 單獨調(diào)用 MethodA 時，在 MethodA 內(nèi)又會調(diào)用 MethodB. 執(zhí)行效果相當(dāng)于 調(diào)用 MethodA 時，環(huán)境中沒有事務(wù)，所以開啟一個新的事務(wù) . 當(dāng)在 MethodA 中調(diào)用MethodB 時，環(huán)境中已經(jīng)有了一個事務(wù)，所以 methodB 就加入當(dāng)前事務(wù)。
l PROPAGATION_SUPPORTS 如果存在一個事務(wù)，支持當(dāng)前事務(wù)。如果沒有事務(wù)，則非事務(wù)的執(zhí)行。但是對于事務(wù)同步的事務(wù)管理器， PROPAGATION_SUPPORTS 與不使用事務(wù)有少許不同。 單純的調(diào)用 methodB 時， methodB 方法是非事務(wù)的執(zhí)行的。 當(dāng)調(diào)用 methdA時 ,methodB 則加入了 methodA 的事務(wù)中 , 事務(wù)地執(zhí)行。
l PROPAGATION_MANDATORY 如果已經(jīng)存在一個事務(wù)，支持當(dāng)前事務(wù)。如果沒有一個活動的事務(wù)，則拋出異常。 當(dāng)單獨調(diào)用 methodB 時，因為當(dāng)前沒有一個活動的事務(wù)，則會拋出異常 throw new IllegalTransactionStateException("Transaction propagation ''mandatory'' but no existing transaction found"); 當(dāng)調(diào)用 methodA 時， methodB 則加入到 methodA 的事務(wù)中，事務(wù)地執(zhí)行。
l PROPAGATION_REQUIRES_NEW 總是開啟一個新的事務(wù)。如果一個事務(wù)已經(jīng)存在，則將這個存在的事務(wù)掛起。 當(dāng)單獨調(diào)用 methodB 時，相當(dāng)于把 methodb 聲明為 REQUIRED 。開啟一個新的事務(wù)，事務(wù)地執(zhí)行。 當(dāng)調(diào)用 methodA 時 情況有些大不一樣 . 相當(dāng)于下面的效果。 在這里，我把 ts1 稱為外層事務(wù)， ts2 稱為內(nèi)層事務(wù)。從上面的代碼可以看出， ts2 與ts1 是兩個獨立的事務(wù)，互不相干。 Ts2 是否成功并不依賴于 ts1 。如果 methodA 方法在調(diào)用 methodB 方法后的 doSomeThingB 方法失敗了，而 methodB 方法所做的結(jié)果依然被提交。而除了 methodB 之外的其它代碼導(dǎo)致的結(jié)果卻被回滾了。 使用PROPAGATION_REQUIRES_NEW, 需要使用 JtaTransactionManager 作為事務(wù)管理器。
l PROPAGATION_NOT_SUPPORTED 總是非事務(wù)地執(zhí)行，并掛起任何存在的事務(wù)。 當(dāng)單獨調(diào)用 methodB 時，不啟用任何事務(wù)機(jī)制，非事務(wù)地執(zhí)行。 當(dāng)調(diào)用 methodA 時，相當(dāng)于下面的效果 使用 PROPAGATION_NOT_SUPPORTED, 也需要使用 JtaTransactionManager 作為事務(wù)管理器。
l PROPAGATION_NEVER 總是非事務(wù)地執(zhí)行，如果存在一個活動事務(wù)，則拋出異常 單獨調(diào)用methodB ，則非事務(wù)的執(zhí)行。 調(diào)用 methodA 則會拋出異常
l PROPAGATION_NESTED 如果一個活動的事務(wù)存在，則運行在一個嵌套的事務(wù)中 . 如果沒有活動事務(wù) , 則按 TransactionDefinition.PROPAGATION_REQUIRED 屬性執(zhí)行 這是一個嵌套事務(wù) , 使用 JDBC 3.0 驅(qū)動時 , 僅僅支持 DataSourceTransactionManager 作為事務(wù)管理器。需要 JDBC 驅(qū)動的 java.sql.Savepoint 類。有一些 JTA 的事務(wù)管理器實現(xiàn)可能也提供了同樣的功能。 使用 PROPAGATION_NESTED ，還需要把 PlatformTransactionManager 的nestedTransactionAllowed 屬性設(shè)為 true; 而 nestedTransactionAllowed 屬性值默認(rèn)為false; 如果單獨調(diào)用 methodB 方法，則按 REQUIRED 屬性執(zhí)行。 如果調(diào)用 methodA 方法，相當(dāng)于下面的效果 當(dāng) methodB 方法調(diào)用之前，調(diào)用 setSavepoint 方法，保存當(dāng)前的狀態(tài)到 savepoint 。如果 methodB 方法調(diào)用失敗，則恢復(fù)到之前保存的狀態(tài)。但是需要注意的是，這時的事務(wù)并沒有進(jìn)行提交，如果后續(xù)的代碼 (doSomeThingB() 方法 ) 調(diào)用失敗，則回滾包括 methodB 方法的所有操作。 嵌套事務(wù)一個非常重要的概念就是內(nèi)層事務(wù)依賴于外層事務(wù)。外層事務(wù)失敗時，會回滾內(nèi)層事務(wù)所做的動作。而內(nèi)層事務(wù)操作失敗并不會引起外層事務(wù)的回滾。
PROPAGATION_NESTED 與 PROPAGATION_REQUIRES_NEW 的區(qū)別：
它們非常類似 , 都像一個嵌套事務(wù)，如果不存在一個活動的事務(wù)，都會開啟一個新的事務(wù)。使用PROPAGATION_REQUIRES_NEW 時，內(nèi)層事務(wù)與外層事務(wù)就像兩個獨立的事務(wù)一樣，一旦內(nèi)層事務(wù)進(jìn)行了提交后，外層事務(wù)不能對其進(jìn)行回滾。兩個事務(wù)互不影響。兩個事務(wù)這是一個真正的嵌套事務(wù)。同時它需要 JTA 事務(wù)管理器的支持。 使用 PROPAGATION_NESTED 時，外層事務(wù)的回滾可以引起內(nèi)層事務(wù)的回滾。而內(nèi)層事務(wù)的異常并不會導(dǎo)致外層事務(wù)的回滾，它是一個真正的嵌套事務(wù)。 DataSourceTransactionManager 使用 savepoint 支持PROPAGATION_NESTED 時，需要 JDBC 3.0 以上驅(qū)動及 1.4 以上的 JDK 版本支持。其它的JTA TrasactionManager 實現(xiàn)可能有不同的支持方式。 PROPAGATION_REQUIRED 應(yīng)該是我們首先的事務(wù)傳播行為。它能夠滿足我們大多數(shù)的事務(wù)需求。