Spring的Transaction

Spring 事務屬性分析

事務管理對於企業應用而言相當重要。它保證了用戶的每一次操做都是可靠的，即使出現了異常的訪問狀況，也不至於破壞後臺數據的完整性。就像銀行的自助取款機，一般都能正常爲客戶服務，可是也不免遇到操做過程當中機器忽然出故障的狀況，此時，事務就必須確保出故障前對帳戶的操做不生效，就像用戶剛纔徹底沒有使用過取款機同樣，以保證用戶和銀行的利益都不受損失。

在 Spring 中，事務是經過 TransactionDefinition 接口來定義的。該接口包含與事務屬性有關的方法。具體如清單1所示：

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

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

也許你會奇怪，爲何接口只提供了獲取屬性的方法，而沒有提供相關設置屬性的方法。其實道理很簡單，事務屬性的設置徹底是程序員控制的，所以程序員能夠自定義任何設置屬性的方法，並且保存屬性的字段也沒有任何要求。惟一的要求的是，Spring 進行事務操做的時候，經過調用以上接口提供的方法必須可以返回事務相關的屬性取值。

事務隔離級別

隔離級別是指若干個併發的事務之間的隔離程度。TransactionDefinition 接口中定義了五個表示隔離級別的常量：

• TransactionDefinition.ISOLATION_DEFAULT：這是默認值，表示使用底層數據庫的默認隔離級別。對大部分數據庫而言，一般這值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
• TransactionDefinition.ISOLATION_READ_UNCOMMITTED：該隔離級別表示一個事務能夠讀取另外一個事務修改但尚未提交的數據。該級別不能防止髒讀和不可重複讀，所以不多使用該隔離級別。
• TransactionDefinition.ISOLATION_READ_COMMITTED：該隔離級別表示一個事務只能讀取另外一個事務已經提交的數據。該級別能夠防止髒讀，這也是大多數狀況下的推薦值。
• TransactionDefinition.ISOLATION_REPEATABLE_READ：該隔離級別表示一個事務在整個過程當中能夠屢次重複執行某個查詢，而且每次返回的記錄都相同。即便在屢次查詢之間有新增的數據知足該查詢，這些新增的記錄也會被忽略。該級別能夠防止髒讀和不可重複讀。
• TransactionDefinition.ISOLATION_SERIALIZABLE：全部的事務依次逐個執行，這樣事務之間就徹底不可能產生干擾，也就是說，該級別能夠防止髒讀、不可重複讀以及幻讀。可是這將嚴重影響程序的性能。一般狀況下也不會用到該級別。

事務傳播行爲

所謂事務的傳播行爲是指，若是在開始當前事務以前，一個事務上下文已經存在，此時有若干選項能夠指定一個事務性方法的執行行爲。在TransactionDefinition定義中包括了以下幾個表示傳播行爲的常量：

• TransactionDefinition.PROPAGATION_REQUIRED：若是當前存在事務，則加入該事務；若是當前沒有事務，則建立一個新的事務。
• TransactionDefinition.PROPAGATION_REQUIRES_NEW：建立一個新的事務，若是當前存在事務，則把當前事務掛起。
• TransactionDefinition.PROPAGATION_SUPPORTS：若是當前存在事務，則加入該事務；若是當前沒有事務，則以非事務的方式繼續運行。
• TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事務方式運行，若是當前存在事務，則把當前事務掛起。
• TransactionDefinition.PROPAGATION_NEVER：以非事務方式運行，若是當前存在事務，則拋出異常。
• TransactionDefinition.PROPAGATION_MANDATORY：若是當前存在事務，則加入該事務；若是當前沒有事務，則拋出異常。
• TransactionDefinition.PROPAGATION_NESTED：若是當前存在事務，則建立一個事務做爲當前事務的嵌套事務來運行；若是當前沒有事務，則該取值等價於TransactionDefinition.PROPAGATION_REQUIRED。

這裏須要指出的是，前面的六種事務傳播行爲是 Spring 從 EJB 中引入的，他們共享相同的概念。而 PROPAGATION_NESTED是 Spring 所特有的。以 PROPAGATION_NESTED 啓動的事務內嵌於外部事務中（若是存在外部事務的話），此時，內嵌事務並非一個獨立的事務，它依賴於外部事務的存在，只有經過外部的事務提交，才能引發內部事務的提交，嵌套的子事務不能單獨提交。若是熟悉 JDBC 中的保存點（SavePoint）的概念，那嵌套事務就很容易理解了，其實嵌套的子事務就是保存點的一個應用，一個事務中能夠包括多個保存點，每個嵌套子事務。另外，外部事務的回滾也會致使嵌套子事務的回滾。

事務超時

所謂事務超時，就是指一個事務所容許執行的最長時間，若是超過該時間限制但事務尚未完成，則自動回滾事務。在 TransactionDefinition 中以 int 的值來表示超時時間，其單位是秒。

事務的只讀屬性

事務的只讀屬性是指，對事務性資源進行只讀操做或者是讀寫操做。所謂事務性資源就是指那些被事務管理的資源，好比數據源、 JMS 資源，以及自定義的事務性資源等等。若是肯定只對事務性資源進行只讀操做，那麼咱們能夠將事務標誌爲只讀的，以提升事務處理的性能。在 TransactionDefinition 中以 boolean 類型來表示該事務是否只讀。

事務的回滾規則

一般狀況下，若是在事務中拋出了未檢查異常（繼承自 RuntimeException 的異常），則默認將回滾事務。若是沒有拋出任何異常，或者拋出了已檢查異常，則仍然提交事務。這一般也是大多數開發者但願的處理方式，也是 EJB 中的默認處理方式。可是，咱們能夠根據須要人爲控制事務在拋出某些未檢查異常時任然提交事務，或者在拋出某些已檢查異常時回滾事務。

---------------------------------------------------------

Spring 事務管理 API 分析

Spring 框架中，涉及到事務管理的 API 大約有100個左右，其中最重要的有三個：TransactionDefinition、PlatformTransactionManager、TransactionStatus。所謂事務管理，其實就是「按照給定的事務規則來執行提交或者回滾操做」。「給定的事務規則」就是用 TransactionDefinition 表示的，「按照……來執行提交或者回滾操做」即是用 PlatformTransactionManager 來表示，而 TransactionStatus 用於表示一個運行着的事務的狀態。打一個不恰當的比喻，TransactionDefinition 與 TransactionStatus 的關係就像程序和進程的關係。

TransactionDef...

該接口在前面已經介紹過，它用於定義一個事務。它包含了事務的靜態屬性，好比：事務傳播行爲、超時時間等等。Spring 爲咱們提供了一個默認的實現類：DefaultTransactionDefinition，該類適用於大多數狀況。若是該類不能知足需求，能夠經過實現 TransactionDefinition 接口來實現本身的事務定義。

PlatformTrans...

PlatformTransactionManager 用於執行具體的事務操做。接口定義如清單2所示：

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

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

根據底層所使用的不一樣的持久化 API 或框架，PlatformTransactionManager 的主要實現類大體以下：

• DataSourceTransactionManager：適用於使用JDBC和iBatis進行數據持久化操做的狀況。
• HibernateTransactionManager：適用於使用Hibernate進行數據持久化操做的狀況。
• JpaTransactionManager：適用於使用JPA進行數據持久化操做的狀況。
• 另外還有JtaTransactionManager 、JdoTransactionManager、JmsTransactionManager等等。

若是咱們使用JTA進行事務管理，咱們能夠經過 JNDI 和 Spring 的 JtaTransactionManager 來獲取一個容器管理的 DataSource。JtaTransactionManager 不須要知道 DataSource 和其餘特定的資源，由於它將使用容器提供的全局事務管理。而對於其餘事務管理器，好比DataSourceTransactionManager，在定義時須要提供底層的數據源做爲其屬性，也就是 DataSource。與 HibernateTransactionManager 對應的是 SessionFactory，與 JpaTransactionManager 對應的是 EntityManagerFactory 等等。

TransactionStatus

PlatformTransactionManager.getTransaction(…) 方法返回一個 TransactionStatus 對象。返回的TransactionStatus 對象可能表明一個新的或已經存在的事務（若是在當前調用堆棧有一個符合條件的事務）。TransactionStatus 接口提供了一個簡單的控制事務執行和查詢事務狀態的方法。該接口定義如清單3所示：

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

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

編程式事務管理

Spring 的編程式事務管理概述

在 Spring 出現之前，編程式事務管理對基於 POJO 的應用來講是惟一選擇。用過 Hibernate 的人都知道，咱們須要在代碼中顯式調用beginTransaction()、commit()、rollback()等事務管理相關的方法，這就是編程式事務管理。經過 Spring 提供的事務管理 API，咱們能夠在代碼中靈活控制事務的執行。在底層，Spring 仍然將事務操做委託給底層的持久化框架來執行。

基於底層 API 的編程式事務管理

根據PlatformTransactionManager、TransactionDefinition 和 TransactionStatus 三個核心接口，咱們徹底能夠經過編程的方式來進行事務管理。示例代碼如清單4所示：

清單4. 基於底層 API 的事務管理示例代碼

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;
}
}

相應的配置文件如清單5所示：

清單5. 基於底層API的事務管理示例配置文件

<bean id="bankService" class="footmark.spring.core.tx.programmatic.origin.BankServiceImpl">
<property name="bankDao" ref="bankDao"/>
<property name="txManager" ref="transactionManager"/>
<property name="txDefinition">
<bean class="org.springframework.transaction.support.DefaultTransactionDefinition">
<property name="propagationBehaviorName" value="PROPAGATION_REQUIRED"/>
</bean>
</property>
</bean>

如上所示，咱們在類中增長了兩個屬性：一個是 TransactionDefinition 類型的屬性，它用於定義一個事務；另外一個是 PlatformTransactionManager 類型的屬性，用於執行事務管理操做。

若是方法須要實施事務管理，咱們首先須要在方法開始執行前啓動一個事務，調用PlatformTransactionManager.getTransaction(...) 方法即可啓動一個事務。建立並啓動了事務以後，即可以開始編寫業務邏輯代碼，而後在適當的地方執行事務的提交或者回滾。

--------------

基於 TransactionTemplate 的編程式事務管理

經過前面的示例能夠發現，這種事務管理方式很容易理解，但使人頭疼的是，事務管理的代碼散落在業務邏輯代碼中，破壞了原有代碼的條理性，而且每個業務方法都包含了相似的啓動事務、提交/回滾事務的樣板代碼。幸虧，Spring 也意識到了這些，並提供了簡化的方法，這就是 Spring 在數據訪問層很是常見的模板回調模式。如清單6所示：

清單6. 基於 TransactionTemplate 的事務管理示例代碼

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;
}
});
}
}

相應的XML配置以下：

清單 7. 基於 TransactionTemplate 的事務管理示例配置文件

<bean id="bankService"
class="footmark.spring.core.tx.programmatic.template.BankServiceImpl">
<property name="bankDao" ref="bankDao"/>
<property name="transactionTemplate" ref="transactionTemplate"/>
</bean>

TransactionTemplate 的 execute() 方法有一個 TransactionCallback 類型的參數，該接口中定義了一個 doInTransaction() 方法，一般咱們以匿名內部類的方式實現 TransactionCallback 接口，並在其 doInTransaction() 方法中書寫業務邏輯代碼。這裏可使用默認的事務提交和回滾規則，這樣在業務代碼中就不須要顯式調用任何事務管理的 API。doInTransaction() 方法有一個TransactionStatus 類型的參數，咱們能夠在方法的任何位置調用該參數的 setRollbackOnly() 方法將事務標識爲回滾的，以執行事務回滾。

根據默認規則，若是在執行回調方法的過程當中拋出了未檢查異常，或者顯式調用了TransacationStatus.setRollbackOnly() 方法，則回滾事務；若是事務執行完成或者拋出了 checked 類型的異常，則提交事務。

TransactionCallback 接口有一個子接口 TransactionCallbackWithoutResult，該接口中定義了一個 doInTransactionWithoutResult() 方法，TransactionCallbackWithoutResult 接口主要用於事務過程當中不須要返回值的狀況。固然，對於不須要返回值的狀況，咱們仍然可使用 TransactionCallback 接口，並在方法中返回任意值便可。

------------------

聲明式事務管理

Spring 的聲明式事務管理概述

Spring 的聲明式事務管理在底層是創建在 AOP 的基礎之上的。其本質是對方法先後進行攔截，而後在目標方法開始以前建立或者加入一個事務，在執行完目標方法以後根據執行狀況提交或者回滾事務。

聲明式事務最大的優勢就是不須要經過編程的方式管理事務，這樣就不須要在業務邏輯代碼中摻瑣事務管理的代碼，只需在配置文件中作相關的事務規則聲明（或經過等價的基於標註的方式），即可以將事務規則應用到業務邏輯中。由於事務管理自己就是一個典型的橫切邏輯，正是 AOP 的用武之地。Spring 開發團隊也意識到了這一點，爲聲明式事務提供了簡單而強大的支持。

聲明式事務管理曾經是 EJB 引覺得傲的一個亮點，現在 Spring 讓 POJO 在事務管理方面也擁有了和 EJB 同樣的待遇，讓開發人員在 EJB 容器以外也用上了強大的聲明式事務管理功能，這主要得益於 Spring 依賴注入容器和 Spring AOP 的支持。依賴注入容器爲聲明式事務管理提供了基礎設施，使得 Bean 對於 Spring 框架而言是可管理的；而 Spring AOP 則是聲明式事務管理的直接實現者，這一點經過清單8能夠看出來。

一般狀況下，筆者強烈建議在開發中使用聲明式事務，不只由於其簡單，更主要是由於這樣使得純業務代碼不被污染，極大方便後期的代碼維護。

和編程式事務相比，聲明式事務惟一不足地方是，後者的最細粒度只能做用到方法級別，沒法作到像編程式事務那樣能夠做用到代碼塊級別。可是即使有這樣的需求，也存在不少變通的方法，好比，能夠將須要進行事務管理的代碼塊獨立爲方法等等。

下面就來看看 Spring 爲咱們提供的聲明式事務管理功能。

基於 TransactionInter... 的聲明式事務管理

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

清單 8. 基於 TransactionInterceptor 的事務管理示例配置文件

<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>

首先，咱們配置了一個 TransactionInterceptor 來定義相關的事務規則，他有兩個主要的屬性：一個是 transactionManager，用來指定一個事務管理器，並將具體事務相關的操做委託給它；另外一個是 Properties 類型的 transactionAttributes 屬性，它主要用來定義事務規則，該屬性的每個鍵值對中，鍵指定的是方法名，方法名可使用通配符，而值就表示相應方法的所應用的事務屬性。

指定事務屬性的取值有較複雜的規則，這在 Spring 中算得上是一件讓人頭疼的事。具體的書寫規則以下：

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

• 傳播行爲是惟一必須設置的屬性，其餘均可以忽略，Spring爲咱們提供了合理的默認值。
• 傳播行爲的取值必須以「PROPAGATION_」開頭，具體包括：PROPAGATION_MANDATORY、PROPAGATION_NESTED、PROPAGATION_NEVER、PROPAGATION_NOT_SUPPORTED、PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、PROPAGATION_SUPPORTS，共七種取值。
• 隔離級別的取值必須以「ISOLATION_」開頭，具體包括：ISOLATION_DEFAULT、ISOLATION_READ_COMMITTED、ISOLATION_READ_UNCOMMITTED、ISOLATION_REPEATABLE_READ、ISOLATION_SERIALIZABLE，共五種取值。
• 若是事務是隻讀的，那麼咱們能夠指定只讀屬性，使用「readOnly」指定。不然咱們不須要設置該屬性。
• 超時屬性的取值必須以「TIMEOUT_」開頭，後面跟一個int類型的值，表示超時時間，單位是秒。
• 不影響提交的異常是指，即便事務中拋出了這些類型的異常，事務任然正常提交。必須在每個異常的名字前面加上「+」。異常的名字能夠是類名的一部分。好比「+RuntimeException」、「+tion」等等。
• 致使回滾的異常是指，當事務中拋出這些類型的異常時，事務將回滾。必須在每個異常的名字前面加上「-」。異常的名字能夠是類名的所有或者部分，好比「-RuntimeException」、「-tion」等等。

如下是兩個示例：

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

以上表達式表示，針對全部方法名以 Service 結尾的方法，使用 PROPAGATION_REQUIRED 事務傳播行爲，事務的隔離級別是 ISOLATION_READ_COMMITTED，超時時間爲20秒，當事務拋出 AbcException 或者 DefException 類型的異常，則仍然提交，當拋出 HijException 類型的異常時必須回滾事務。這裏沒有指定"readOnly"，表示事務不是隻讀的。

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

以上表達式表示，針對全部方法名爲 test 的方法，使用 PROPAGATION_REQUIRED 事務傳播行爲，而且該事務是隻讀的。除此以外，其餘的屬性均使用默認值。好比，隔離級別和超時時間使用底層事務性資源的默認值，而且當發生未檢查異常，則回滾事務，發生已檢查異常則仍提交事務。

配置好了 TransactionInterceptor，咱們還須要配置一個 ProxyFactoryBean 來組裝 target 和advice。這也是典型的 Spring AOP 的作法。經過 ProxyFactoryBean 生成的代理類就是織入了事務管理邏輯後的目標類。至此，聲明式事務管理就算是實現了。咱們沒有對業務代碼進行任何操做，全部設置均在配置文件中完成，這就是聲明式事務的最大優勢。

基於 TransactionProxy... 的聲明式事務管理

前面的聲明式事務雖然好，可是卻存在一個很是惱人的問題：配置文件太多。咱們必須針對每個目標對象配置一個 ProxyFactoryBean；另外，雖然能夠經過父子 Bean 的方式來複用 TransactionInterceptor 的配置，可是實際的複用概率也不高；這樣，加上目標對象自己，每個業務類可能須要對應三個 <bean/> 配置，隨着業務類的增多，配置文件將會變得愈來愈龐大，管理配置文件又成了問題。

爲了緩解這個問題，Spring 爲咱們提供了 TransactionProxyFactoryBean，用於將TransactionInterceptor 和 ProxyFactoryBean 的配置合二爲一。如清單9所示：

清單9. 基於 TransactionProxyFactoryBean 的事務管理示例配置文件

<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>

如此一來，配置文件與先前相比簡化了不少。咱們把這種配置方式稱爲 Spring 經典的聲明式事務管理。相信在早期使用 Spring 的開發人員對這種配置聲明式事務的方式必定很是熟悉。

可是，顯式爲每個業務類配置一個 TransactionProxyFactoryBean 的作法將使得代碼顯得過於刻板，爲此咱們可使用自動建立代理的方式來將其簡化，使用自動建立代理是純 AOP 知識，請讀者參考相關文檔，不在此贅述。

--------------------

基於 <tx> 命名空間的聲明式事務管理

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

如清單10所示：

清單10. 基於 <tx> 的事務管理示例配置文件

<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>

若是默認的事務屬性就能知足要求，那麼代碼簡化爲如清單 11 所示：

清單 11. 簡化後的基於 <tx> 的事務管理示例配置文件

<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>

因爲使用了切點表達式，咱們就不須要針對每個業務類建立一個代理對象了。另外，若是配置的事務管理器 Bean 的名字取值爲「transactionManager」，則咱們能夠省略 <tx:advice> 的 transaction-manager 屬性，由於該屬性的默認值即爲「transactionManager」。

基於 @Transactional 的聲明式事務管理

除了基於命名空間的事務配置方式，Spring 2.x 還引入了基於 Annotation 的方式，具體主要涉及@Transactional 標註。@Transactional 能夠做用於接口、接口方法、類以及類方法上。看成用於類上時，該類的全部 public 方法將都具備該類型的事務屬性，同時，咱們也能夠在方法級別使用該標註來覆蓋類級別的定義。如清單12所示：

清單12. 基於 @Transactional 的事務管理示例配置文件

@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，若是事務管理器 Bean 的名字即爲該值，則能夠省略該屬性。

雖然 @Transactional 註解能夠做用於接口、接口方法、類以及類方法上，可是 Spring 小組建議不要在接口或者接口方法上使用該註解，由於這隻有在使用基於接口的代理時它纔會生效。另外， @Transactional 註解應該只被應用到 public 方法上，這是由 Spring AOP 的本質決定的。若是你在 protected、private 或者默承認見性的方法上使用 @Transactional 註解，這將被忽略，也不會拋出任何異常。

基於 <tx> 命名空間和基於 @Transactional 的事務聲明方式各有優缺點。基於 <tx> 的方式，其優勢是與切點表達式結合，功能強大。利用切點表達式，一個配置能夠匹配多個方法，而基於 @Transactional 的方式必須在每個須要使用事務的方法或者類上用 @Transactional 標註，儘管可能大多數事務的規則是一致的，可是對 @Transactional 而言，也沒法重用，必須逐個指定。另外一方面，基於 @Transactional 的方式使用起來很是簡單明瞭，沒有學習成本。開發人員能夠根據須要，任選其中一種使用，甚至也能夠根據須要混合使用這兩種方式。

若是不是對遺留代碼進行維護，則不建議再使用基於 TransactionInterceptor 以及基於TransactionProxyFactoryBean 的聲明式事務管理方式，可是，學習這兩種方式很是有利於對底層實現的理解。

雖然上面共列舉了四種聲明式事務管理方式，可是這樣的劃分只是爲了便於理解，其實後臺的實現方式是同樣的，只是用戶使用的方式不一樣而已。

回頁首

結束語

本教程的知識點大體總結以下：

• 基於 TransactionDefinition、PlatformTransactionManager、TransactionStatus 編程式事務管理是 Spring 提供的最原始的方式，一般咱們不會這麼寫，可是瞭解這種方式對理解 Spring 事務管理的本質有很大做用。
• 基於 TransactionTemplate 的編程式事務管理是對上一種方式的封裝，使得編碼更簡單、清晰。
• 基於 TransactionInterceptor 的聲明式事務是 Spring 聲明式事務的基礎，一般也不建議使用這種方式，可是與前面同樣，瞭解這種方式對理解 Spring 聲明式事務有很大做用。
• 基於 TransactionProxyFactoryBean 的聲明式事務是上中方式的改進版本，簡化的配置文件的書寫，這是 Spring 早期推薦的聲明式事務管理方式，可是在 Spring 2.0 中已經不推薦了。
• 基於 <tx> 和 <aop> 命名空間的聲明式事務管理是目前推薦的方式，其最大特色是與 Spring AOP 結合緊密，能夠充分利用切點表達式的強大支持，使得管理事務更加靈活。
• 基於 @Transactional 的方式將聲明式事務管理簡化到了極致。開發人員只需在配置文件中加上一行啓用相關後處理 Bean 的配置，而後在須要實施事務管理的方法或者類上使用 @Transactional 指定事務規則便可實現事務管理，並且功能也沒必要其餘方式遜色。