開始之前
關於本教程
本教程將深入講解 Spring 簡單而強大的事務管理功能，包括編程式事務和聲明式事務。通過對本教程的學習，您將能夠理解 Spring 事務管理的本質，並靈活運用之。
先決條件
本教程假定您已經掌握了 Java 基礎知識，並對 Spring 有一定了解。您還需要具備基本的事務管理的知識，比如：事務的定義，隔離級別的概念，等等。本文將直接使用這些概念而不做詳細解釋。另外，您最好掌握數據庫的基礎知識，雖然這不是必須。
系統需求
要試驗這份教程中的工具和示例，硬件配置需求爲：至少帶有 512MB 內存（推薦 1GB）的系統。需要安裝以下軟件：
Sun JDK 5.0 或更新版本或 IBM Developer Kit for the Java 5 platform 版本。
Spring framework 2.5。本教程附帶的示例代碼已經在 Spring 2.5.6 上測試過。
MySQL 5.0 或更新版本。
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">
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
<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>