您當前位置：首頁 > php開源 > 綜合技術(shù) > 全面分析 Spring 的編程式事務(wù)管理及聲明式事務(wù)管理

全面分析 Spring 的編程式事務(wù)管理及聲明式事務(wù)管理

來源：程序員人生發(fā)布時間：2016-06-06 08:18:51 閱讀次數(shù)：3734次

Spring 事務(wù)屬性分析

事務(wù)管理對企業(yè)利用而言相當重要。它保證了用戶的每次操作都是可靠的，即使出現(xiàn)了異常的訪問情況，也不至于破壞后臺數(shù)據(jù)的完全性。就像銀行的自助取款機，通常都能正常為客戶服務(wù)，但是也難免遇到操作進程中機器突然出故障的情況，此時，事務(wù)就必須確保出故障前對賬戶的操作不生效，就像用戶剛才完全沒有使用過取款機1樣，以保證用戶和銀行的利益都不受損失。

在 Spring 中，事務(wù)是通過 TransactionDefinition 接口來定義的。該接口包括與事務(wù)屬性有關(guān)的方法。具體如清單1所示：

清單1. TransactionDefinition 接口中定義的主要方法

public interface TransactionDefinition{ int getIsolationLevel(); int getPropagationBehavior(); int getTimeout(); boolean isReadOnly(); }

或許你會奇怪，為何接口只提供了獲得屬性的方法，而沒有提供相干設(shè)置屬性的方法。其實道理很簡單，事務(wù)屬性的設(shè)置完全是程序員控制的，因此程序員可以自定義任何設(shè)置屬性的方法，而且保存屬性的字段也沒有任何要求。唯1的要求的是，Spring 進行事務(wù)操作的時候，通過調(diào)用以上接口提供的方法必須能夠返回事務(wù)相干的屬性取值。

事務(wù)隔離級別

隔離級別是指若干個并發(fā)的事務(wù)之間的隔離程度。TransactionDefinition 接口中定義了5個表示隔離級別的常量：

TransactionDefinition.ISOLATION_DEFAULT：這是默許值，表示使用底層數(shù)據(jù)庫的默許隔離級別。對大部份數(shù)據(jù)庫而言，通常這值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
TransactionDefinition.ISOLATION_READ_UNCOMMITTED：該隔離級別表示1個事務(wù)可以讀取另外一個事務(wù)修改但還沒有提交的數(shù)據(jù)。該級別不能避免臟讀和不可重復讀，因此很少使用該隔離級別。
TransactionDefinition.ISOLATION_READ_COMMITTED：該隔離級別表示1個事務(wù)只能讀取另外一個事務(wù)已提交的數(shù)據(jù)。該級別可以避免臟讀，這也是大多數(shù)情況下的推薦值。
TransactionDefinition.ISOLATION_REPEATABLE_READ：該隔離級別表示1個事務(wù)在全部進程中可以屢次重復履行某個查詢，并且每次返回的記錄都相同。即便在屢次查詢之間有新增的數(shù)據(jù)滿足該查詢，這些新增的記錄也會被疏忽。該級別可以避免臟讀和不可重復讀。
TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事務(wù)順次逐一履行，這樣事務(wù)之間就完全不可能產(chǎn)生干擾，也就是說，該級別可以避免臟讀、不可重復讀和幻讀。但是這將嚴重影響程序的性能。通常情況下也不會用到該級別。

事務(wù)傳播行動

所謂事務(wù)的傳播行動是指，如果在開始當前事務(wù)之前，1個事務(wù)上下文已存在，此時有若干選項可以指定1個事務(wù)性方法的履行行動。在TransactionDefinition定義中包括了以下幾個表示傳播行動的常量：

TransactionDefinition.PROPAGATION_REQUIRED：如果當前存在事務(wù)，則加入該事務(wù)；如果當前沒有事務(wù)，則創(chuàng)建1個新的事務(wù)。
TransactionDefinition.PROPAGATION_REQUIRES_NEW：創(chuàng)建1個新的事務(wù)，如果當前存在事務(wù)，則把當前事務(wù)掛起。
TransactionDefinition.PROPAGATION_SUPPORTS：如果當前存在事務(wù)，則加入該事務(wù)；如果當前沒有事務(wù)，則以非事務(wù)的方式繼續(xù)運行。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事務(wù)方式運行，如果當前存在事務(wù)，則把當前事務(wù)掛起。
TransactionDefinition.PROPAGATION_NEVER：以非事務(wù)方式運行，如果當前存在事務(wù)，則拋出異常。
TransactionDefinition.PROPAGATION_MANDATORY：如果當前存在事務(wù)，則加入該事務(wù)；如果當前沒有事務(wù)，則拋出異常。
TransactionDefinition.PROPAGATION_NESTED：如果當前存在事務(wù)，則創(chuàng)建1個事務(wù)作為當前事務(wù)的嵌套事務(wù)來運行；如果當前沒有事務(wù)，則該取值等價于TransactionDefinition.PROPAGATION_REQUIRED。

這里需要指出的是，前面的6種事務(wù)傳播行動是 Spring 從 EJB 中引入的，他們同享相同的概念。而 PROPAGATION_NESTED是 Spring 所獨有的。以 PROPAGATION_NESTED 啟動的事務(wù)內(nèi)嵌于外部事務(wù)中（如果存在外部事務(wù)的話），此時，內(nèi)嵌事務(wù)其實不是1個獨立的事務(wù)，它依賴于外部事務(wù)的存在，只有通過外部的事務(wù)提交，才能引發(fā)內(nèi)部事務(wù)的提交，嵌套的子事務(wù)不能單獨提交。如果熟習 JDBC 中的保存點（SavePoint）的概念，那嵌套事務(wù)就很容易理解了，其實嵌套的子事務(wù)就是保存點的1個利用，1個事務(wù)中可以包括多個保存點，每個嵌套子事務(wù)。另外，外部事務(wù)的回滾也會致使嵌套子事務(wù)的回滾。

事務(wù)超時

所謂事務(wù)超時，就是指1個事務(wù)所允許履行的最長時間，如果超過該時間限制但事務(wù)還沒有完成，則自動回滾事務(wù)。在 TransactionDefinition 中以 int 的值來表示超時時間，其單位是秒。

事務(wù)的只讀屬性

事務(wù)的只讀屬性是指，對事務(wù)性資源進行只讀操作或是讀寫操作。所謂事務(wù)性資源就是指那些被事務(wù)管理的資源，比如數(shù)據(jù)源、 JMS 資源，和自定義的事務(wù)性資源等等。如果肯定只對事務(wù)性資源進行只讀操作，那末我們可以將事務(wù)標志為只讀的，以提高事務(wù)處理的性能。在 TransactionDefinition 中以 boolean 類型來表示該事務(wù)是不是只讀。

事務(wù)的回滾規(guī)則

通常情況下，如果在事務(wù)中拋出了未檢查異常（繼承自 RuntimeException 的異常），則默許將回滾事務(wù)。如果沒有拋出任何異常，或拋出了已檢查異常，則依然提交事務(wù)。這通常也是大多數(shù)開發(fā)者希望的處理方式，也是 EJB 中的默許處理方式。但是，我們可以根據(jù)需要人為控制事務(wù)在拋出某些未檢查異常時任然提交事務(wù)，或在拋出某些已檢查異常時回滾事務(wù)。

回頁首

Spring 事務(wù)管理 API 分析

Spring 框架中，觸及到事務(wù)管理的 API 大約有100個左右，其中最重要的有3個：TransactionDefinition、PlatformTransactionManager、TransactionStatus。所謂事務(wù)管理，其實就是“依照給定的事務(wù)規(guī)則來履行提交或回滾操作”。“給定的事務(wù)規(guī)則”就是用 TransactionDefinition 表示的，“依照……來履行提交或回滾操作”便是用 PlatformTransactionManager 來表示，而 TransactionStatus 用于表示1個運行著的事務(wù)的狀態(tài)。打1個不恰當?shù)谋扔鳎琓ransactionDefinition 與 TransactionStatus 的關(guān)系就像程序和進程的關(guān)系。

TransactionDef...

該接口在前面已介紹過，它用于定義1個事務(wù)。它包括了事務(wù)的靜態(tài)屬性，比如：事務(wù)傳播行動、超時時間等等。Spring 為我們提供了1個默許的實現(xiàn)類：DefaultTransactionDefinition，該類適用于大多數(shù)情況。如果該類不能滿足需求，可以通過實現(xiàn) TransactionDefinition 接口來實現(xiàn)自己的事務(wù)定義。

PlatformTrans...

PlatformTransactionManager 用于履行具體的事務(wù)操作。接口定義如清單2所示：

清單2. PlatformTransactionManager 接口中定義的主要方法

Public interface PlatformTransactionManager{ TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException; void commit(TransactionStatus status)throws TransactionException; void rollback(TransactionStatus status)throws TransactionException; }

根據(jù)底層所使用的不同的持久化 API 或框架，PlatformTransactionManager 的主要實現(xiàn)類大致以下：

DataSourceTransactionManager：適用于使用JDBC和iBatis進行數(shù)據(jù)持久化操作的情況。
HibernateTransactionManager：適用于使用Hibernate進行數(shù)據(jù)持久化操作的情況。
JpaTransactionManager：適用于使用JPA進行數(shù)據(jù)持久化操作的情況。
另外還有JtaTransactionManager 、JdoTransactionManager、JmsTransactionManager等等。

如果我們使用JTA進行事務(wù)管理，我們可以通過 JNDI 和 Spring 的 JtaTransactionManager 來獲得1個容器管理的 DataSource。JtaTransactionManager 不需要知道 DataSource 和其他特定的資源，由于它將使用容器提供的全局事務(wù)管理。而對其他事務(wù)管理器，比如DataSourceTransactionManager，在定義時需要提供底層的數(shù)據(jù)源作為其屬性，也就是 DataSource。與 HibernateTransactionManager 對應(yīng)的是 SessionFactory，與 JpaTransactionManager 對應(yīng)的是 EntityManagerFactory 等等。

TransactionStatus

PlatformTransactionManager.getTransaction(…) 方法返回1個 TransactionStatus 對象。返回的TransactionStatus 對象可能代表1個新的或已存在的事務(wù)（如果在當前調(diào)用堆棧有1個符合條件的事務(wù)）。TransactionStatus 接口提供了1個簡單的控制事務(wù)履行和查詢事務(wù)狀態(tài)的方法。該接口定義如清單3所示：

清單3. TransactionStatus 接口中定義的主要方法

public interface TransactionStatus{ boolean isNewTransaction(); void setRollbackOnly(); boolean isRollbackOnly(); }

回頁首

編程式事務(wù)管理

Spring 的編程式事務(wù)管理概述

在 Spring 出現(xiàn)之前，編程式事務(wù)管理對基于 POJO 的利用來講是唯1選擇。用過 Hibernate 的人都知道，我們需要在代碼中顯式調(diào)用beginTransaction()、commit()、rollback()等事務(wù)管理相干的方法，這就是編程式事務(wù)管理。通過 Spring 提供的事務(wù)管理 API，我們可以在代碼中靈活控制事務(wù)的履行。在底層，Spring 依然將事務(wù)操作拜托給底層的持久化框架來履行。

基于底層 API 的編程式事務(wù)管理

根據(jù)PlatformTransactionManager、TransactionDefinition 和 TransactionStatus 3個核心接口，我們完全可以通過編程的方式來進行事務(wù)管理。示例代碼如清單4所示：

清單4. 基于底層 API 的事務(wù)管理示例代碼

public class BankServiceImpl implements BankService { private BankDao bankDao; private TransactionDefinition txDefinition; private PlatformTransactionManager txManager; ...... public boolean transfer(Long fromId， Long toId， double amount) { TransactionStatus txStatus = txManager.getTransaction(txDefinition); boolean result = false; try { result = bankDao.transfer(fromId， toId， amount); txManager.commit(txStatus); } catch (Exception e) { result = false; txManager.rollback(txStatus); System.out.println("Transfer Error!"); } return result; } }

相應(yīng)的配置文件如清單5所示：

清單5. 基于底層API的事務(wù)管理示例配置文件

如上所示，我們在類中增加了兩個屬性：1個是 TransactionDefinition 類型的屬性，它用于定義1個事務(wù)；另外一個是 PlatformTransactionManager 類型的屬性，用于履行事務(wù)管理操作。

如果方法需要實行事務(wù)管理，我們首先需要在方法開始履行前啟動1個事務(wù)，調(diào)用PlatformTransactionManager.getTransaction(...) 方法即可啟動1個事務(wù)。創(chuàng)建并啟動了事務(wù)以后，即可以開始編寫業(yè)務(wù)邏輯代碼，然后在適當?shù)牡胤铰男惺聞?wù)的提交或回滾。

基于 TransactionTemplate 的編程式事務(wù)管理

通過前面的示例可以發(fā)現(xiàn)，這類事務(wù)管理方式很容易理解，但使人頭疼的是，事務(wù)管理的代碼散落在業(yè)務(wù)邏輯代碼中，破壞了原有代碼的條理性，并且每個業(yè)務(wù)方法都包括了類似的啟動事務(wù)、提交/回滾事務(wù)的樣板代碼。幸虧，Spring 也意想到了這些，并提供了簡化的方法，這就是 Spring 在數(shù)據(jù)訪問層非常常見的模板回調(diào)模式。如清單6所示：

清單6. 基于 TransactionTemplate 的事務(wù)管理示例代碼

public class BankServiceImpl implements BankService { private BankDao bankDao; private TransactionTemplate transactionTemplate; ...... public boolean transfer(final Long fromId， final Long toId， final double amount) { return (Boolean) transactionTemplate.execute(new TransactionCallback(){ public Object doInTransaction(TransactionStatus status) { Object result; try { result = bankDao.transfer(fromId， toId， amount); } catch (Exception e) { status.setRollbackOnly(); result = false; System.out.println("Transfer Error!"); } return result; } }); } }

相應(yīng)的XML配置以下：

清單 7. 基于 TransactionTemplate 的事務(wù)管理示例配置文件

TransactionTemplate 的 execute() 方法有1個 TransactionCallback 類型的參數(shù)，該接口中定義了1個 doInTransaction() 方法，通常我們以匿名內(nèi)部類的方式實現(xiàn) TransactionCallback 接口，并在其 doInTransaction() 方法中書寫業(yè)務(wù)邏輯代碼。這里可使用默許的事務(wù)提交和回滾規(guī)則，這樣在業(yè)務(wù)代碼中就不需要顯式調(diào)用任何事務(wù)管理的 API。doInTransaction() 方法有1個TransactionStatus 類型的參數(shù)，我們可以在方法的任何位置調(diào)用該參數(shù)的 setRollbackOnly() 方法將事務(wù)標識為回滾的，以履行事務(wù)回滾。

根據(jù)默許規(guī)則，如果在履行回調(diào)方法的進程中拋出了未檢查異常，或顯式調(diào)用了TransacationStatus.setRollbackOnly() 方法，則回滾事務(wù)；如果事務(wù)履行完成或拋出了 checked 類型的異常，則提交事務(wù)。

TransactionCallback 接口有1個子接口 TransactionCallbackWithoutResult，該接口中定義了1個 doInTransactionWithoutResult() 方法，TransactionCallbackWithoutResult 接口主要用于事務(wù)進程中不需要返回值的情況。固然，對不需要返回值的情況，我們依然可使用 TransactionCallback 接口，并在方法中返回任意值便可。

回頁首

聲明式事務(wù)管理

Spring 的聲明式事務(wù)管理概述

Spring 的聲明式事務(wù)管理在底層是建立在 AOP 的基礎(chǔ)之上的。其本質(zhì)是對方法前落后行攔截，然后在目標方法開始之前創(chuàng)建或加入1個事務(wù)，在履行完目標方法以后根據(jù)履行情況提交或回滾事務(wù)。

聲明式事務(wù)最大的優(yōu)點就是不需要通過編程的方式管理事務(wù)，這樣就不需要在業(yè)務(wù)邏輯代碼中攙雜事務(wù)管理的代碼，只需在配置文件中做相干的事務(wù)規(guī)則聲明（或通過等價的基于標注的方式），即可以將事務(wù)規(guī)則利用到業(yè)務(wù)邏輯中。由于事務(wù)管理本身就是1個典型的橫切邏輯，正是 AOP 的用武之地。Spring 開發(fā)團隊也意想到了這1點，為聲明式事務(wù)提供了簡單而強大的支持。

聲明式事務(wù)管理曾是 EJB 引以為傲的1個亮點，如今 Spring 讓 POJO 在事務(wù)管理方面也具有了和 EJB 1樣的待遇，讓開發(fā)人員在 EJB 容器以外也用上了強大的聲明式事務(wù)管理功能，這主要得益于 Spring 依賴注入容器和 Spring AOP 的支持。依賴注入容器為聲明式事務(wù)管理提供了基礎(chǔ)設(shè)施，使得 Bean 對 Spring 框架而言是可管理的；而 Spring AOP 則是聲明式事務(wù)管理的直接實現(xiàn)者，這1點通過清單8可以看出來。

通常情況下，筆者強烈建議在開發(fā)中使用聲明式事務(wù)，不但由于其簡單，更主要是由于這樣使得純業(yè)務(wù)代碼不被污染，極大方便后期的代碼保護。

和編程式事務(wù)相比，聲明式事務(wù)唯1不足地方是，后者的最細粒度只能作用到方法級別，沒法做到像編程式事務(wù)那樣可以作用到代碼塊級別。但是即使有這樣的需求，也存在很多變通的方法，比如，可以將需要進行事務(wù)管理的代碼塊獨立為方法等等。

下面就來看看 Spring 為我們提供的聲明式事務(wù)管理功能。

基于 TransactionInter... 的聲明式事務(wù)管理

最初，Spring 提供了 TransactionInterceptor 類來實行聲明式事務(wù)管理功能。先看清單8的配置文件：

清單 8. 基于 TransactionInterceptor 的事務(wù)管理示例配置文件

<beans...> ...... <bean id="transactionInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor"> <property name="transactionManager" ref="transactionManager"/> <property name="transactionAttributes"> <props> <prop key="transfer">PROPAGATION_REQUIRED</prop> </props> </property> </bean> <bean id="bankServiceTarget" class="footmark.spring.core.tx.declare.origin.BankServiceImpl"> <property name="bankDao" ref="bankDao"/> </bean> <bean id="bankService" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="target" ref="bankServiceTarget"/> <property name="interceptorNames"> <list> <idref bean="transactionInterceptor"/> </list> </property> </bean> ...... </beans>

首先，我們配置了1個 TransactionInterceptor 來定義相干的事務(wù)規(guī)則，他有兩個主要的屬性：1個是 transactionManager，用來指定1個事務(wù)管理器，并將具體事務(wù)相干的操作拜托給它；另外一個是 Properties 類型的 transactionAttributes 屬性，它主要用來定義事務(wù)規(guī)則，該屬性的每個鍵值對中，鍵指定的是方法名，方法名可使用通配符，而值就表示相應(yīng)方法的所利用的事務(wù)屬性。

指定事務(wù)屬性的取值有較復雜的規(guī)則，這在 Spring 中算得上是1件讓人頭疼的事。具體的書寫規(guī)則以下：

傳播行動 [，隔離級別] [，只讀屬性] [，超時屬性] [不影響提交的異常] [，致使回滾的異常]

傳播行動是唯1必須設(shè)置的屬性，其他都可以疏忽，Spring為我們提供了公道的默許值。
傳播行動的取值必須以“PROPAGATION_”開頭，具體包括：PROPAGATION_MANDATORY、PROPAGATION_NESTED、PROPAGATION_NEVER、PROPAGATION_NOT_SUPPORTED、PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、PROPAGATION_SUPPORTS，共7種取值。
隔離級別的取值必須以“ISOLATION_”開頭，具體包括：ISOLATION_DEFAULT、ISOLATION_READ_COMMITTED、ISOLATION_READ_UNCOMMITTED、ISOLATION_REPEATABLE_READ、ISOLATION_SERIALIZABLE，共5種取值。
如果事務(wù)是只讀的，那末我們可以指定只讀屬性，使用“readOnly”指定。否則我們不需要設(shè)置該屬性。
超時屬性的取值必須以“TIMEOUT_”開頭，后面跟1個int類型的值，表示超時時間，單位是秒。
不影響提交的異常是指，即便事務(wù)中拋出了這些類型的異常，事務(wù)任然正常提交。必須在每個異常的名字前面加上“+”。異常的名字可以是類名的1部份。比如“+RuntimeException”、“+tion”等等。
致使回滾的異常是指，當事務(wù)中拋出這些類型的異常時，事務(wù)將回滾。必須在每個異常的名字前面加上“-”。異常的名字可以是類名的全部或部份，比如“-RuntimeException”、“-tion”等等。

以下是兩個示例：

<property name="*Service"> PROPAGATION_REQUIRED，ISOLATION_READ_COMMITTED，TIMEOUT_20， +AbcException，+DefException，-HijException </property>

以上表達式表示，針對所有方法名以 Service 結(jié)尾的方法，使用 PROPAGATION_REQUIRED 事務(wù)傳播行動，事務(wù)的隔離級別是 ISOLATION_READ_COMMITTED，超時時間為20秒，當事務(wù)拋出 AbcException 或 DefException 類型的異常，則依然提交，當拋出 HijException 類型的異常時必須回滾事務(wù)。這里沒有指定"readOnly"，表示事務(wù)不是只讀的。

<property name="test">PROPAGATION_REQUIRED，readOnly</property>

以上表達式表示，針對所有方法名為 test 的方法，使用 PROPAGATION_REQUIRED 事務(wù)傳播行動，并且該事務(wù)是只讀的。除此以外，其他的屬性均使用默許值。比如，隔離級別和超時時間使用底層事務(wù)性資源的默許值，并且當產(chǎn)生未檢查異常，則回滾事務(wù)，產(chǎn)生已檢查異常則仍提交事務(wù)。

配置好了 TransactionInterceptor，我們還需要配置1個 ProxyFactoryBean 來組裝 target 和advice。這也是典型的 Spring AOP 的做法。通過 ProxyFactoryBean 生成的代理類就是織入了事務(wù)管理邏輯后的目標類。至此，聲明式事務(wù)管理就算是實現(xiàn)了。我們沒有對業(yè)務(wù)代碼進行任何操作，所有設(shè)置均在配置文件中完成，這就是聲明式事務(wù)的最大優(yōu)點。

基于 TransactionProxy... 的聲明式事務(wù)管理

前面的聲明式事務(wù)雖然好，但是卻存在1個非常惱人的問題：配置文件太多。我們必須針對每個目標對象配置1個 ProxyFactoryBean；另外，雖然可以通過父子 Bean 的方式來復用 TransactionInterceptor 的配置，但是實際的復用概率也不高；這樣，加上目標對象本身，每個業(yè)務(wù)類可能需要對應(yīng)3個 <bean/> 配置，隨著業(yè)務(wù)類的增多，配置文件將會變得愈來愈龐大，管理配置文件又成了問題。

為了減緩這個問題，Spring 為我們提供了 TransactionProxyFactoryBean，用于將TransactionInterceptor 和 ProxyFactoryBean 的配置合2為1。如清單9所示：

清單9. 基于 TransactionProxyFactoryBean 的事務(wù)管理示例配置文件

<beans......> ...... <bean id="bankServiceTarget" class="footmark.spring.core.tx.declare.classic.BankServiceImpl"> <property name="bankDao" ref="bankDao"/> </bean> <bean id="bankService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="target" ref="bankServiceTarget"/> <property name="transactionManager" ref="transactionManager"/> <property name="transactionAttributes"> <props> <prop key="transfer">PROPAGATION_REQUIRED</prop> </props> </property> </bean> ...... </beans>

如此1來，配置文件與先前相比簡化了很多。我們把這類配置方式稱為 Spring 經(jīng)典的聲明式事務(wù)管理。相信在初期使用 Spring 的開發(fā)人員對這類配置聲明式事務(wù)的方式1定非常熟習。

但是，顯式為每個業(yè)務(wù)類配置1個 TransactionProxyFactoryBean 的做法將使得代碼顯得過于呆板，為此我們可使用自動創(chuàng)建代理的方式來將其簡化，使用自動創(chuàng)建代理是純 AOP 知識，請讀者參考相干文檔，不在此贅述。

基于 <tx> 命名空間的聲明式事務(wù)管理

前面兩種聲明式事務(wù)配置方式奠定了 Spring 聲明式事務(wù)管理的基石。在此基礎(chǔ)上，Spring 2.x 引入了 <tx> 命名空間，結(jié)合使用 <aop> 命名空間，帶給開發(fā)人員配置聲明式事務(wù)的全新體驗，配置變得更加簡單和靈活。另外，得益于 <aop> 命名空間的切點表達式支持，聲明式事務(wù)也變得更加強大。

如清單10所示：

清單10. 基于 <tx> 的事務(wù)管理示例配置文件

<beans......> ...... <bean id="bankService" class="footmark.spring.core.tx.declare.namespace.BankServiceImpl"> <property name="bankDao" ref="bankDao"/> </bean> <tx:advice id="bankAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="transfer" propagation="REQUIRED"/> </tx:attributes> </tx:advice> <aop:config> <aop:pointcut id="bankPointcut" expression="execution(* *.transfer(..))"/> <aop:advisor advice-ref="bankAdvice" pointcut-ref="bankPointcut"/> </aop:config> ...... </beans>

如果默許的事務(wù)屬性就可以滿足要求，那末代碼簡化為如清單 11 所示：

清單 11. 簡化后的基于 <tx> 的事務(wù)管理示例配置文件

<beans......> ...... <bean id="bankService" class="footmark.spring.core.tx.declare.namespace.BankServiceImpl"> <property name="bankDao" ref="bankDao"/> </bean> <tx:advice id="bankAdvice" transaction-manager="transactionManager"> <aop:config> <aop:pointcut id="bankPointcut" expression="execution(**.transfer(..))"/> <aop:advisor advice-ref="bankAdvice" pointcut-ref="bankPointcut"/> </aop:config> ...... </beans>

由于使用了切點表達式，我們就不需要針對每個業(yè)務(wù)類創(chuàng)建1個代理對象了。另外，如果配置的事務(wù)管理器 Bean 的名字取值為“transactionManager”，則我們可以省略 <tx:advice> 的 transaction-manager 屬性，由于該屬性的默許值即為“transactionManager”。

基于 @Transactional 的聲明式事務(wù)管理

除基于命名空間的事務(wù)配置方式，Spring 2.x 還引入了基于 Annotation 的方式，具體主要觸及@Transactional 標注。@Transactional 可以作用于接口、接口方法、類和類方法上。當作用于類上時，該類的所有 public 方法將都具有該類型的事務(wù)屬性，同時，我們也能夠在方法級別使用該標注來覆蓋類級別的定義。如清單12所示：

清單12. 基于 @Transactional 的事務(wù)管理示例配置文件

@Transactional(propagation = Propagation.REQUIRED) public boolean transfer(Long fromId， Long toId， double amount) { return bankDao.transfer(fromId， toId， amount); }

Spring 使用 BeanPostProcessor 來處理 Bean 中的標注，因此我們需要在配置文件中作以下聲明來激活該后處理 Bean，如清單13所示：

清單13. 啟用后處理Bean的配置

<tx:annotation-driven transaction-manager="transactionManager"/>

與前面相似，transaction-manager 屬性的默許值是 transactionManager，如果事務(wù)管理器 Bean 的名字即為該值，則可以省略該屬性。

雖然 @Transactional 注解可以作用于接口、接口方法、類和類方法上，但是 Spring 小組建議不要在接口或接口方法上使用該注解，由于這只有在使用基于接口的代理時它才會生效。另外， @Transactional 注解應(yīng)當只被利用到 public 方法上，這是由 Spring AOP 的本質(zhì)決定的。如果你在 protected、private 或默許可見性的方法上使用 @Transactional 注解，這將被疏忽，也不會拋出任何異常。

基于 <tx> 命名空間和基于 @Transactional 的事務(wù)聲明方式各有優(yōu)缺點。基于 <tx> 的方式，其優(yōu)點是與切點表達式結(jié)合，功能強大。利用切點表達式，1個配置可以匹配多個方法，而基于 @Transactional 的方式必須在每個需要使用事務(wù)的方法或類上用 @Transactional 標注，雖然可能大多數(shù)事務(wù)的規(guī)則是1致的，但是對 @Transactional 而言，也沒法重用，必須逐一指定。另外一方面，基于 @Transactional 的方式使用起來非常簡單明了，沒有學習本錢。開發(fā)人員可以根據(jù)需要，任選其中1種使用，乃至也能夠根據(jù)需要混合使用這兩種方式。

如果不是對遺留代碼進行保護，則不建議再使用基于 TransactionInterceptor 和基于TransactionProxyFactoryBean 的聲明式事務(wù)管理方式，但是，學習這兩種方式非常有益于對底層實現(xiàn)的理解。

雖然上面共羅列了4種聲明式事務(wù)管理方式，但是這樣的劃分只是為了便于理解，其實后臺的實現(xiàn)方式是1樣的，只是用戶使用的方式不同而已。

回頁首

結(jié)束語

本教程的知識點大致總結(jié)以下：

基于 TransactionDefinition、PlatformTransactionManager、TransactionStatus 編程式事務(wù)管理是 Spring 提供的最原始的方式，通常我們不會這么寫，但是了解這類方式對理解 Spring 事務(wù)管理的本質(zhì)有很大作用。
基于 TransactionTemplate 的編程式事務(wù)管理是對上1種方式的封裝，使得編碼更簡單、清晰。
基于 TransactionInterceptor 的聲明式事務(wù)是 Spring 聲明式事務(wù)的基礎(chǔ)，通常也不建議使用這類方式，但是與前面1樣，了解這類方式對理解 Spring 聲明式事務(wù)有很大作用。
基于 TransactionProxyFactoryBean 的聲明式事務(wù)是上中方式的改進版本，簡化的配置文件的書寫，這是 Spring 初期推薦的聲明式事務(wù)管理方式，但是在 Spring 2.0 中已不推薦了。
基于 <tx> 和 <aop> 命名空間的聲明式事務(wù)管理是目前推薦的方式，其最大特點是與 Spring AOP 結(jié)合緊密，可以充分利用切點表達式的強大支持，使得管理事務(wù)更加靈活。
基于 @Transactional 的方式將聲明式事務(wù)管理簡化到了極致。開發(fā)人員只需在配置文件中加上1行啟用相干后處理 Bean 的配置，然后在需要實行事務(wù)管理的方法或類上使用 @Transactional 指定事務(wù)規(guī)則便可實現(xiàn)事務(wù)管理，而且功能也沒必要其他方式遜色。

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
程序員人生

------分隔線----------------------------

上一篇 QQ 聊天機器人小薇發(fā)布！

下一篇 Spark 定制版：010~Spark Streaming源碼解讀之流數(shù)據(jù)不斷接收全生命周期徹底研究和思考

分享到: