qqjianyue代碼工

Spring 聲明式事務讓我們從復雜的事務處理中得到解脫。使得我們再也無需要去處理獲得連接、關閉連接、事務提交和回滾等這些操作。再也無需要我們在與事務相關的方法中處理大量的 try… catch … finally 代碼。 我們在使用 Spring 聲明式事務時，有一個非常重要的概念就是事務屬性。事務屬性通常由事務的傳播行為，事務的隔離級別，事務的超時值和事務只讀標志組成。我們在進行事務劃分時，需要進行事務定義，也就是配置事務的屬性。

Spring 在 TransactionDefinition 接口中定義這些屬性 , 以供 PlatfromTransactionManager 使用 , PlatfromTransactionManager 是 spring 事務管理的核心接口。

l         getTimeout() 方法，它返回事務必須在多少秒內完成。

l         isReadOnly() , 事務是否只讀，事務管理器能夠根據這個返回值進行優化，確保事務是只讀的。

l         getIsolationLevel() 方法返回事務的隔離級別，事務管理器根據它來控制另外一個事務可以看到本事務內的哪些數據。

在 TransactionDefinition 接口中定義了五個不同的事務隔離級別：

l         ISOLATION_DEFAULT 這是一個 PlatfromTransactionManager 默認的隔離級別，使用數據庫默認的事務隔離級別 . 另外四個與 JDBC 的隔離級別相對應

l         ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別，它充許別外一個事務可以看到這個事務未提交的數據。這種隔離級別會產生臟讀，不可重復讀和幻像讀。 例如 : Mary的原工資為 1000, 財務人員將 Mary 的工資改為了 8000 ，但未提交事務 與此同時， Mary正在讀取自己的工資 Mary 發現自己的工資變為了 8000 ，歡天喜地！ 而財務發現操作有誤，而回滾了事務 ,Mary 的工資又變為了 1000. 像這樣 ,Mary 記取的工資數 8000 是一個臟數據。

l         ISOLATION_READ_COMMITTED 保證一個事務修改的數據提交后才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數據。這種事務隔離級別可以避免臟讀出現，但是可能會出現不可重復讀和幻像讀。

l         ISOLATION_REPEATABLE_READ 這種事務隔離級別可以防止臟讀，不可重復讀。但是可能出現幻像讀。它除了保證一個事務不能讀取另一個事務未提交的數據外，還保證了避免下面的情況產生 ( 不可重復讀 ) 。 在事務 1 中， Mary 讀取了自己的工資為 1000, 操作并沒有完成 在事務 2 中，這時財務人員修改了 Mary 的工資為 2000, 并提交了事務 . 在事務 1 中，Mary 再次讀取自己的工資時，工資變為了 2000 在一個事務中前后兩次讀取的結果并不致，導致了不可重復讀。 使用 ISOLATION_REPEATABLE_READ 可以避免這種情況發生。

l         ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。除了防止臟讀，不可重復讀外，還避免了幻像讀。 目前工資為 1000 的員工有 10人。 事務 1, 讀取所有工資為 1000 的員工。 共讀取 10 條記錄 這時另一個事務向 employee表插入了一條員工記錄，工資也為 1000 事務 1 再次讀取所有工資為 1000 的員工 共讀取到了 11 條記錄，這就產生了幻像讀。 ISOLATION_SERIALIZABLE 能避免這樣的情況發生。但是這樣也耗費了最大的資源。

getPropagationBehavior () 返回事務的傳播行為，由是否有一個活動的事務來決定一個事務調用。 在 TransactionDefinition 接口中定義了七個事務傳播行為：

l         PROPAGATION_REQUIRED 如果存在一個事務，則支持當前事務。如果沒有事務則開啟一個新的事務。 使用 spring 聲明式事務， spring 使用 AOP 來支持聲明式事務，會根據事務屬性，自動在方法調用之前決定是否開啟一個事務，并在方法執行之后決定事務提交或回滾事務。 單獨調用 methodB 方法 相當于 Spring 保證在 methodB 方法中所有的調用都獲得到一個相同的連接。在調用 methodB 時，沒有一個存在的事務，所以獲得一個新的連接，開啟了一個新的事務。 單獨調用 MethodA 時，在 MethodA 內又會調用 MethodB. 執行效果相當于 調用 MethodA 時，環境中沒有事務，所以開啟一個新的事務 . 當在 MethodA 中調用MethodB 時，環境中已經有了一個事務，所以 methodB 就加入當前事務。

l         PROPAGATION_SUPPORTS 如果存在一個事務，支持當前事務。如果沒有事務，則非事務的執行。但是對于事務同步的事務管理器， PROPAGATION_SUPPORTS 與不使用事務有少許不同。 單純的調用 methodB 時， methodB 方法是非事務的執行的。 當調用 methdA時 ,methodB 則加入了 methodA 的事務中 , 事務地執行。

l         PROPAGATION_MANDATORY 如果已經存在一個事務，支持當前事務。如果沒有一個活動的事務，則拋出異常。 當單獨調用 methodB 時，因為當前沒有一個活動的事務，則會拋出異常 throw new IllegalTransactionStateException("Transaction propagation ''mandatory'' but no existing transaction found"); 當調用 methodA 時， methodB 則加入到 methodA 的事務中，事務地執行。

l         PROPAGATION_REQUIRES_NEW 總是開啟一個新的事務。如果一個事務已經存在，則將這個存在的事務掛起。 當單獨調用 methodB 時，相當于把 methodb 聲明為 REQUIRED 。開啟一個新的事務，事務地執行。 當調用 methodA 時 情況有些大不一樣 . 相當于下面的效果。 在這里，我把 ts1 稱為外層事務， ts2 稱為內層事務。從上面的代碼可以看出， ts2 與ts1 是兩個獨立的事務，互不相干。 Ts2 是否成功并不依賴于 ts1 。如果 methodA 方法在調用 methodB 方法后的 doSomeThingB 方法失敗了，而 methodB 方法所做的結果依然被提交。而除了 methodB 之外的其它代碼導致的結果卻被回滾了。 使用PROPAGATION_REQUIRES_NEW, 需要使用 JtaTransactionManager 作為事務管理器。

l         PROPAGATION_NOT_SUPPORTED 總是非事務地執行，并掛起任何存在的事務。 當單獨調用 methodB 時，不啟用任何事務機制，非事務地執行。 當調用 methodA 時，相當于下面的效果 使用 PROPAGATION_NOT_SUPPORTED, 也需要使用 JtaTransactionManager 作為事務管理器。

l         PROPAGATION_NEVER 總是非事務地執行，如果存在一個活動事務，則拋出異常 單獨調用methodB ，則非事務的執行。 調用 methodA 則會拋出異常

l         PROPAGATION_NESTED 如果一個活動的事務存在，則運行在一個嵌套的事務中 . 如果沒有活動事務 , 則按 TransactionDefinition.PROPAGATION_REQUIRED 屬性執行 這是一個嵌套事務 , 使用 JDBC 3.0 驅動時 , 僅僅支持 DataSourceTransactionManager 作為事務管理器。需要 JDBC 驅動的 java.sql.Savepoint 類。有一些 JTA 的事務管理器實現可能也提供了同樣的功能。 使用 PROPAGATION_NESTED ，還需要把 PlatformTransactionManager 的nestedTransactionAllowed 屬性設為 true; 而 nestedTransactionAllowed 屬性值默認為false; 如果單獨調用 methodB 方法，則按 REQUIRED 屬性執行。 如果調用 methodA 方法，相當于下面的效果 當 methodB 方法調用之前，調用 setSavepoint 方法，保存當前的狀態到 savepoint 。如果 methodB 方法調用失敗，則恢復到之前保存的狀態。但是需要注意的是，這時的事務并沒有進行提交，如果后續的代碼 (doSomeThingB() 方法 ) 調用失敗，則回滾包括 methodB 方法的所有操作。 嵌套事務一個非常重要的概念就是內層事務依賴于外層事務。外層事務失敗時，會回滾內層事務所做的動作。而內層事務操作失敗并不會引起外層事務的回滾。

PROPAGATION_NESTED 與 PROPAGATION_REQUIRES_NEW 的區別：

它們非常類似 , 都像一個嵌套事務，如果不存在一個活動的事務，都會開啟一個新的事務。使用PROPAGATION_REQUIRES_NEW 時，內層事務與外層事務就像兩個獨立的事務一樣，一旦內層事務進行了提交后，外層事務不能對其進行回滾。兩個事務互不影響。兩個事務這是一個真正的嵌套事務。同時它需要 JTA 事務管理器的支持。 使用 PROPAGATION_NESTED 時，外層事務的回滾可以引起內層事務的回滾。而內層事務的異常并不會導致外層事務的回滾，它是一個真正的嵌套事務。 DataSourceTransactionManager 使用 savepoint 支持PROPAGATION_NESTED 時，需要 JDBC 3.0 以上驅動及 1.4 以上的 JDK 版本支持。其它的JTA TrasactionManager 實現可能有不同的支持方式。 PROPAGATION_REQUIRED 應該是我們首先的事務傳播行為。它能夠滿足我們大多數的事務需求。

1. Clean Lifecycle
   • pre-clean
   • clean
   • post-clean
2. Default Lifecycle
   • validate
   • initialize
   • generate-sources
   • process-sources
   • generate-resources
   • process-resources
   • compile
   • process-classes
   • generate-test-sources
   • process-test-sources
   • process-test-resources
   • test-compile
   • process-test-classes
   • test
   • prepare-package
   • package
   • pre-integration-test
   • integration-test
   • post-integration-test
   • verify
   • install
   • deploy
3. Site Lifecycle
   • pre-site
   • site
   • post-site
   • site-deploy