全面分析 Spring 的程式設計式事務管理及聲明式事務管理

全面分析 Spring 的程式設計式事務管理及聲明式事務管理

本教程将深入講解 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 中，事務是通過 TransactionDefinition 接口來定義的。該接口包含與事務屬性有關的方法。具體如清單1所示：

也許你會奇怪，為什麼接口隻提供了擷取屬性的方法，而沒有提供相關設定屬性的方法。其實道理很簡單，事務屬性的設定完全是程式員控制的，是以程式員可以自定義任何設定屬性的方法，而且儲存屬性的字段也沒有任何要求。唯一的要求的是，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 大約有100個左右，其中最重要的有三個：TransactionDefinition、PlatformTransactionManager、TransactionStatus。所謂事務管理，其實就是“按照給定的事務規則來執行送出或者復原操作”。“給定的事務規則”就是用 TransactionDefinition 表示的，“按照……來執行送出或者復原操作”便是用 PlatformTransactionManager 來表示，而 TransactionStatus 用于表示一個運作着的事務的狀态。打一個不恰當的比喻，TransactionDefinition 與 TransactionStatus 的關系就像程式和程序的關系。

該接口在前面已經介紹過，它用于定義一個事務。它包含了事務的靜态屬性，比如：事務傳播行為、逾時時間等等。Spring 為我們提供了一個預設的實作類：DefaultTransactionDefinition，該類适用于大多數情況。如果該類不能滿足需求，可以通過實作 TransactionDefinition 接口來實作自己的事務定義。

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

根據底層所使用的不同的持久化 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 等等。

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

在 Spring 出現以前，程式設計式事務管理對基于 POJO 的應用來說是唯一選擇。用過 Hibernate 的人都知道，我們需要在代碼中顯式調用beginTransaction()、commit()、rollback()等事務管理相關的方法，這就是程式設計式事務管理。通過 Spring 提供的事務管理 API，我們可以在代碼中靈活控制事務的執行。在底層，Spring 仍然将事務操作委托給底層的持久化架構來執行。

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

相應的配置檔案如清單5所示：

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

如果方法需要實施事務管理，我們首先需要在方法開始執行前啟動一個事務，調用PlatformTransactionManager.getTransaction(...) 方法便可啟動一個事務。建立并啟動了事務之後，便可以開始編寫業務邏輯代碼，然後在适當的地方執行事務的送出或者復原。

通過前面的示例可以發現，這種事務管理方式很容易了解，但令人頭疼的是，事務管理的代碼散落在業務邏輯代碼中，破壞了原有代碼的條理性，并且每一個業務方法都包含了類似的啟動事務、送出/復原事務的樣闆代碼。幸好，Spring 也意識到了這些，并提供了簡化的方法，這就是 Spring 在資料通路層非常常見的模闆回調模式。如清單6所示：

相應的XML配置如下：

TransactionTemplate 的 execute() 方法有一個 TransactionCallback 類型的參數，該接口中定義了一個 doInTransaction() 方法，通常我們以匿名内部類的方式實作 TransactionCallback 接口，并在其 doInTransaction() 方法中書寫業務邏輯代碼。這裡可以使用預設的事務送出和復原規則，這樣在業務代碼中就不需要顯式調用任何事務管理的 API。doInTransaction() 方法有一個TransactionStatus 類型的參數，我們可以在方法的任何位置調用該參數的 setRollbackOnly() 方法将事務辨別為復原的，以執行事務復原。

根據預設規則，如果在執行回調方法的過程中抛出了未檢查異常，或者顯式調用了TransacationStatus.setRollbackOnly() 方法，則復原事務；如果事務執行完成或者抛出了 checked 類型的異常，則送出事務。

TransactionCallback 接口有一個子接口 TransactionCallbackWithoutResult，該接口中定義了一個 doInTransactionWithoutResult() 方法，TransactionCallbackWithoutResult 接口主要用于事務過程中不需要傳回值的情況。當然，對于不需要傳回值的情況，我們仍然可以使用 TransactionCallback 接口，并在方法中傳回任意值即可。

Spring 的聲明式事務管理在底層是建立在 AOP 的基礎之上的。其本質是對方法前後進行攔截，然後在目标方法開始之前建立或者加入一個事務，在執行完目标方法之後根據執行情況送出或者復原事務。

聲明式事務最大的優點就是不需要通過程式設計的方式管理事務，這樣就不需要在業務邏輯代碼中摻雜事務管理的代碼，隻需在配置檔案中做相關的事務規則聲明（或通過等價的基于标注的方式），便可以将事務規則應用到業務邏輯中。因為事務管理本身就是一個典型的橫切邏輯，正是 AOP 的用武之地。Spring 開發團隊也意識到了這一點，為聲明式事務提供了簡單而強大的支援。

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

通常情況下，筆者強烈建議在開發中使用聲明式事務，不僅因為其簡單，更主要是因為這樣使得純業務代碼不被污染，極大友善後期的代碼維護。

和程式設計式事務相比，聲明式事務唯一不足地方是，後者的最細粒度隻能作用到方法級别，無法做到像程式設計式事務那樣可以作用到代碼塊級别。但是即便有這樣的需求，也存在很多變通的方法，比如，可以将需要進行事務管理的代碼塊獨立為方法等等。

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

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

首先，我們配置了一個 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”等等。

以下是兩個示例：

以上表達式表示，針對所有方法名以 Service 結尾的方法，使用 PROPAGATION_REQUIRED 事務傳播行為，事務的隔離級别是 ISOLATION_READ_COMMITTED，逾時時間為20秒，當事務抛出 AbcException 或者 DefException 類型的異常，則仍然送出，當抛出 HijException 類型的異常時必須復原事務。這裡沒有指定"readOnly"，表示事務不是隻讀的。

以上表達式表示，針對所有方法名為 test 的方法，使用 PROPAGATION_REQUIRED 事務傳播行為，并且該事務是隻讀的。除此之外，其他的屬性均使用預設值。比如，隔離級别和逾時時間使用底層事務性資源的預設值，并且當發生未檢查異常，則復原事務，發生已檢查異常則仍送出事務。

配置好了 TransactionInterceptor，我們還需要配置一個 ProxyFactoryBean 來組裝 target 和advice。這也是典型的 Spring AOP 的做法。通過 ProxyFactoryBean 生成的代理類就是織入了事務管理邏輯後的目标類。至此，聲明式事務管理就算是實作了。我們沒有對業務代碼進行任何操作，所有設定均在配置檔案中完成，這就是聲明式事務的最大優點。

前面的聲明式事務雖然好，但是卻存在一個非常惱人的問題：配置檔案太多。我們必須針對每一個目标對象配置一個 ProxyFactoryBean；另外，雖然可以通過父子 Bean 的方式來複用 TransactionInterceptor 的配置，但是實際的複用幾率也不高；這樣，加上目标對象本身，每一個業務類可能需要對應三個 <bean/> 配置，随着業務類的增多，配置檔案将會變得越來越龐大，管理配置檔案又成了問題。

為了緩解這個問題，Spring 為我們提供了 TransactionProxyFactoryBean，用于将TransactionInterceptor 和 ProxyFactoryBean 的配置合二為一。如清單9所示：

如此一來，配置檔案與先前相比簡化了很多。我們把這種配置方式稱為 Spring 經典的聲明式事務管理。相信在早期使用 Spring 的開發人員對這種配置聲明式事務的方式一定非常熟悉。

但是，顯式為每一個業務類配置一個 TransactionProxyFactoryBean 的做法将使得代碼顯得過于刻闆，為此我們可以使用自動建立代理的方式來将其簡化，使用自動建立代理是純 AOP 知識，請讀者參考相關文檔，不在此贅述。

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

如清單10所示：

如果預設的事務屬性就能滿足要求，那麼代碼簡化為如清單 11 所示：

由于使用了切點表達式，我們就不需要針對每一個業務類建立一個代理對象了。另外，如果配置的事務管理器 Bean 的名字取值為“transactionManager”，則我們可以省略 <tx:advice> 的 transaction-manager 屬性，因為該屬性的預設值即為“transactionManager”。

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

Spring 使用 BeanPostProcessor 來處理 Bean 中的标注，是以我們需要在配置檔案中作如下聲明來激活該後處理 Bean，如清單13所示：

與前面相似，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 指定事務規則即可實作事務管理，而且功能也不必其他方式遜色。