Spring提供了一致的事務管理抽象。這個抽象是Spring最重要的抽象之一， 提供如下的優點：
傳統上，J2EE開發者有兩個事務管理的選擇: 全局或 局部事務。全局事務由應用服務器管理，使用JTA。局部 事務是資源相關的：例如，一個和JDBC連接關聯的事務。這個選擇有深刻的含義。 全局事務提供和多個參與事務的資源（需要指出的是多數應用使用單一參與事務 的資源）。使用局部事務，應用服務器不需要參與事務管理，并且不能幫助確保 跨越多個資源的正確性。
全局事務有一個顯著的不利方面，代碼需要使用JTA：一個笨重的API（部分是 因為它的異常模型）。此外，JTA UserTransaction通常需 要從JNDI獲得，意味著我需要同時使用JNDI和JTA來使用 JTA。顯然全部使用全局事務限制了應用代碼的重用性，因為JTA通常只在應用服 務器的環境中才能使用。
首選的使用全局事務的方式是通過EJB的CMT (容器管理的事務): 一種形式的 聲明式事務管理（區別于編程式事務管理 ）。EJB的CMT消除了事務相關的JNDI查找的需求，雖然使用EJB本身 肯定需要使用JNDI。它消除大多數――不是全部――書寫Java代碼控制事務的需求。 顯著的不利方面是CMT和JTA以及應用服務器環境捆綁在一起，并且只有我們選擇 使用EJB實現業務邏輯時才能使用，或者至少使用在一個事務化EJB的外觀 （Fa?ade）后。EJB有如此多的詬病，當存在可供選擇的聲明式事務管理時， EJB不是一個吸引人的建議。
局部事務容易使用，但也有明顯的不利方面：它們不能跨越多個參與事務的資 源使用，并且趨向侵入的編程模型。例如，使用JDBC連接事務管理的代碼不能使 在全局的JTA事務中。
Spring解決了這些問題。它使應用開發者能夠使用在任何環境 下使用一致的編程模型。你可以只寫一次你的代碼，這些代碼可以從在不同環境 下的不同事務管理策略中獲益。Spring同時提供聲明式和編程式事務管理。
使用編程式事務管理，開發者使用Spring事務抽象，這個抽象可以使用的任何 底層事務基礎之上。使用首選的聲明式模型，開發者通常書寫很少的事務相關代 碼，因此不依賴Spring或任何其他事務API。
Spring提供兩種方式的編程式事務管理
我們通常推薦使用第一種方式。
第二種方式類似使用JTA UserTransaction API （雖然異常處理少一點麻煩）。
Spring也提供了聲明式事務管理。這是通過Spring AOP實現的。
從考慮EJB CMT和Spring聲明式事務管理的相似以及不同之處出發是很有益的。 基本方法是一致的：都可以指定事務管理到單獨的方法；如果需要可以在事務上 下文調用setRollbackOnly()方法。不同之處：
-
不同于EJB CMT綁定在JTA上，Spring聲明式事務管理可以在任何環境下使用。 只需更改配置文件，它就可以和JDBC、JDO、Hibernate或其他的事務機制一起工作
-
Spring可以使聲明式事務管理應用到POJO，不僅僅是特定的類，如EJB
-
Spring提供聲明式回滾規則：EJB沒有對應的特性， 我們將在下面討論這個特性。回滾可以聲明式控制，不僅僅是編程式的
-
Spring通過AOP提供定制事務行為的機會。例如，如果需要，你可以在事務 回滾中插入定制的行為。你也可以增加事務通知一樣增加任意的通知。使用 EJB CMT，除了使用setRollbackOnly()沒有其他的辦法能 夠影響容器的事務管理
-
Spring不提供高端應用服務器提供的跨越遠程調用的事務上下文傳播。如 果你需要這些特性，我們推薦你使用EJB。然而，不要過度使用這些特性。通常我 們并不希望事務跨越遠程調用
回滾規則的概念是很重要的：它們使得我們可以指定那些異常應該發起一個自 動回滾。我們在配置文件中而不是Java代碼中指定這些聲明。因此，雖然我們仍 然可以編程式調用TransactionStatus對象的 setRollbackOnly()方法來回滾當前事務，多數時候我們可以 指定規則如MyApplicationException應該用于導致一個回滾。 這有顯著的優點，業務對象不需要依賴事務基礎設施。例如，他們通常不需要引 入任何Spring API,事務或其他任何東西。
EJB的默認行為是遇到系統異常（通常是運行時異常） EJB容器自動回滾事務。EJB CMT遇到應用程序異常 （除了java.rmi.RemoteException外被檢查的異常）時不 會自動回滾事務。雖然Spring聲明式事務管理沿用EJB CMT約定（遇到不被檢查的 異常自動回滾事務），但是這是可以定制的。
按照我們的基準，Spring聲明式事務管理的性能要勝過EJB CMT。
通常設置Spring事務代理的方法是通過TransactionProxyFactoryBean。我們需 要一個包裝在事務代理中目標對象。這個目標對象一般是一個POJO的bean。當我 們定義TransactionProxyFactoryBean時，必須提供一個相關的 PlatformTransactionManager的引用和事務屬性。 事務屬性含有上面描述的事務定義。
<bean id="petStore"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager"><ref bean="transactionManager"/></property>
<property name="target"><ref bean="petStoreTarget"/></property>
<property name="transactionAttributes">
<props>
<prop key="insert*">PROPAGATION_REQUIRED,-MyCheckedException</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
事務代理會實現目標對象的接口：這里是id為petStoreTarget.的bean（使用 CGLIB可以實現具體類的代理，只要設置proxyTargetClass屬性為true就可以。這 將自動設置，如果目標對象沒有實現任何接口。通常，我們希望面向接口而不是 類編程）。可以（一般來說是好的想法）限定事務代理使用proxyInterfaces來代 理指定的接口。也可以通過繼承至 org.springframework.aop.framework.ProxyConfig幾個屬 性來定制TransactionProxyFactoryBean的行為，并在所有的AOP代理工廠中共享。
這里的transactionAttributes通過定在 org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource 類中的屬性格式來設置。這個包括通配符的方法名稱映射是很直觀的。注意 insert*的映射的值包括回滾規則。添加-MyCheckedException 指定如果方法拋出MyCheckedException或它的子類，事務將 會自動回滾。可以指定個回滾規則，用逗號分隔。-前綴強制回滾，+前綴指定提 交（這允許即使拋出未被檢查的異常時也可以提交事務，當然你自己要明白自己 在做什么）。
TransactionProxyFactoryBean允許你通過 “preInterceptors”和“postInterceptors”屬性設置“前”或“后”通知來提供額外的 攔截行為。可以設置任意數量的“前”和“后”通知，它們的類型可以是 Advisor（可以包含一個pointcut）， MethodInterceptor或被當前Spring配置支持的通知類型 （例如ThrowAdvice， AfterReturningtAdvice或BeforeAdvice， 這些都是默認支持的）。這些通知必須支持實例共享模式。如果你需要高級AOP特 性來使用事務，如有狀態的混入，那最好使用通用的 org.springframework.aop.framework.ProxyFactoryBean， 而不是TransactionProxyFactoryBean代理創建者。
也可以設置自動代理：配置AOP框架，不需要單獨的代理定義類就可以生成類的 代理。
更多信息和實例請參閱AOP章節。
如果你只有很少的事務操作，使用編程式事務管理是很好的主意。例如， 如果你有一個WEB應用需要為某些更新操作提供事務，你可能不想用Spring或其 他技術設置一個事務代理。使用 TransactionTemplate可能是個很好的方法。
另一方面，如果你的應用有大量的事務操作，編程式（譯注：應為聲明式， 疑是作者筆誤）事務管理通常是很有價值的。它使得事務管理從業務邏輯分離， 并且Spring中配置也不困難。使用Spring， 而不是EJB CMT，聲明式事務管理配置的成本極大地降低。
Spring的事務管理能力――尤其聲明式事務管理極大地改變了J2EE應用程序需要 應用服務器的傳統想法。
特別地，你不需要應用服務器僅僅為了通過EJB聲明事務。事實上，即使你擁 有強大JTA支持的應用服務器，你也可以決定使用Spring聲明式事務管理提供比 EJB CMT更強大更高效的編程模型。
只有需要支持多個事務資源時你才需要應用服務器的JTA支持。許多應用沒有 這個需求。例如許多高端應用使用單一的高度可升級的數據庫，如Oracle 9i RAC。
當然也許你需要其他應用服務器的功能，如JMS和JCA。但是如果你只需使用 JTA，你可以考慮開源的JTA實現，如JOTM（Spring整合了JOTM）。但是， 2004年早期，高端的應用服務器提供更健壯的XA資源支持。
最重要一點，使用Spring，你可以選擇何時將你的應用遷移到完整 應用服務器。除了使用EJB CMT和JTA只能書寫代碼使用局部事務， 例如JDBC連接的事務，而且如果曾經需要全局的容器管理的事務，還面臨著繁重 的改寫過程，這些日子一去不復返了。使用Spring只有配置需要改變，你的代碼 不需要。
開發著需要按照需求仔細的使用正確的 PlatformTransactionManager實現。
理解Spring事務抽象時如何和JTA全局事務一起工作是非常重要的。使用得當， 沒有任何沖突：Spring僅僅提供一個簡單的，可以移植的抽象層。
如果你使用全局事務，你必須為你的所有事務操作使用Spring的 org.springframework.transaction.jta.JtaTransactionManager。 否則Spring將試圖在資源如容器數據源執行局部事務。這樣的局部事務沒有任何 意義，好的應用服務器會把這作為一個錯誤。