首先，我們配置了一個 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 的方式使用起來非常簡單明瞭，沒有學習成本。開發人員可以根據需要，任選其中一種使用，甚至也可以根據需要混合使用這兩種方式。
雖然上面共列舉了四種聲明式事務管理方式，但是這樣的劃分只是爲了便於理解，其實後臺的實現方式是一樣的，只是用戶使用的方式不同而已。
結束語
本教程的知識點大致總結如下：
基於 TransactionDefinition、PlatformTransactionManager、TransactionStatus 編程式事務管理是 Spring 提供的最原始的方式，通常我們不會這麼寫，但是瞭解這種方式對理解 Spring 事務管理的本質有很大作用。
基於 TransactionTemplate 的編程式事務管理是對上一種方式的封裝，使得編碼更簡單、清晰。
基於 TransactionInterceptor 的聲明式事務是 Spring 聲明式事務的基礎，通常也不建議使用這種方式，但是與前面一樣，瞭解這種方式對理解 Spring 聲明式事務有很大作用。
基於 TransactionProxyFactoryBean 的聲明式事務是上中方式的改進版本，簡化的配置文件的書寫，這是 Spring 早期推薦的聲明式事務管理方式，但是在 Spring 2.0 中已經不推薦了。
基於 <tx> 和 <aop> 命名空間的聲明式事務管理是目前推薦的方式，其最大特點是與 Spring AOP 結合緊密，可以充分利用切點表達式的強大支持，使得管理事務更加靈活。
基於 @Transactional 的方式將聲明式事務管理簡化到了極致。開發人員只需在配置文件中加上一行啓用相關後處理 Bean 的配置，然後在需要實施事務管理的方法或者類上使用 @Transactional 指定事務規則即可實現事務管理，而且功能也不必其他方式遜色
