Spring提供了一致的事務(wù)管理抽象。這個(gè)抽象是Spring最重要的抽象之一， 提供如下的優(yōu)點(diǎn)：

傳統(tǒng)上，J2EE開發(fā)者有兩個(gè)事務(wù)管理的選擇: 全局或 局部事務(wù)。全局事務(wù)由應(yīng)用服務(wù)器管理，使用JTA。局部 事務(wù)是資源相關(guān)的：例如，一個(gè)和JDBC連接關(guān)聯(lián)的事務(wù)。這個(gè)選擇有深刻的含義。 全局事務(wù)提供和多個(gè)參與事務(wù)的資源（需要指出的是多數(shù)應(yīng)用使用單一參與事務(wù) 的資源）。使用局部事務(wù)，應(yīng)用服務(wù)器不需要參與事務(wù)管理，并且不能幫助確保 跨越多個(gè)資源的正確性。

全局事務(wù)有一個(gè)顯著的不利方面，代碼需要使用JTA：一個(gè)笨重的API（部分是 因?yàn)樗漠惓ＤＰ停?。此外，JTA UserTransaction通常需 要從JNDI獲得，意味著我需要同時(shí)使用JNDI和JTA來(lái)使用 JTA。顯然全部使用全局事務(wù)限制了應(yīng)用代碼的重用性，因?yàn)镴TA通常只在應(yīng)用服 務(wù)器的環(huán)境中才能使用。

首選的使用全局事務(wù)的方式是通過(guò)EJB的CMT (容器管理的事務(wù)): 一種形式的 聲明式事務(wù)管理（區(qū)別于編程式事務(wù)管理 ）。EJB的CMT消除了事務(wù)相關(guān)的JNDI查找的需求，雖然使用EJB本身 肯定需要使用JNDI。它消除大多數(shù)――不是全部――書寫Java代碼控制事務(wù)的需求。 顯著的不利方面是CMT和JTA以及應(yīng)用服務(wù)器環(huán)境捆綁在一起，并且只有我們選擇 使用EJB實(shí)現(xiàn)業(yè)務(wù)邏輯時(shí)才能使用，或者至少使用在一個(gè)事務(wù)化EJB的外觀 （Fa?ade）后。EJB有如此多的詬病，當(dāng)存在可供選擇的聲明式事務(wù)管理時(shí)， EJB不是一個(gè)吸引人的建議。

局部事務(wù)容易使用，但也有明顯的不利方面：它們不能跨越多個(gè)參與事務(wù)的資 源使用，并且趨向侵入的編程模型。例如，使用JDBC連接事務(wù)管理的代碼不能使 在全局的JTA事務(wù)中。

Spring解決了這些問題。它使應(yīng)用開發(fā)者能夠使用在任何環(huán)境 下使用一致的編程模型。你可以只寫一次你的代碼，這些代碼可以從在不同環(huán)境 下的不同事務(wù)管理策略中獲益。Spring同時(shí)提供聲明式和編程式事務(wù)管理。

使用編程式事務(wù)管理，開發(fā)者使用Spring事務(wù)抽象，這個(gè)抽象可以使用的任何 底層事務(wù)基礎(chǔ)之上。使用首選的聲明式模型，開發(fā)者通常書寫很少的事務(wù)相關(guān)代 碼，因此不依賴Spring或任何其他事務(wù)API。

Spring事務(wù)抽象的關(guān)鍵是事務(wù)策略的概念。

這個(gè)概念由 org.springframework.transaction.PlatformTransactionManager 接口表達(dá)，如下：

public interface PlatformTransactionManager {

    TransactionStatus getTransaction(TransactionDefinition definition)
        throws TransactionException;

    void commit(TransactionStatus status) throws TransactionException;

    void rollback(TransactionStatus status) throws TransactionException;
}

這首先是一個(gè)SPI接口，雖然它也可以在編碼中使用。注意按照Spring的哲學(xué)， 這是一個(gè)接口。因而如果需要它可以很容易地被模擬和 樁化。它也沒有和一個(gè)查找策略如JNDI捆綁在一起：PlatformTransactionManager 的實(shí)現(xiàn)定義和其他Spring IoC容器中的對(duì)象一樣。這個(gè)好處使得即使使用JTA這也 是一個(gè)很有價(jià)值的抽象：事務(wù)代碼可以比直接使用JTA更加容易測(cè)試。

繼續(xù)Spring哲學(xué)，TransactionException是不被檢查的。 低層的事務(wù)失敗幾乎都是一成不變地致命。很少情況下應(yīng)用程序代碼可以從它們 中恢復(fù)，不過(guò)應(yīng)用開發(fā)者依然可以捕獲并處理 TransactionException。

getTransaction()根據(jù)一個(gè) TransactionDefinition類型參數(shù)返回一個(gè) TransactionStatus對(duì)象，返回的 TransactionStatus對(duì)象可以代表一個(gè)新的或已經(jīng)存在的事 務(wù)（如果在當(dāng)前調(diào)用堆棧有一個(gè)符合條件的事務(wù)）。

如同J2EE事務(wù)上下文，一個(gè)TransactionStatus也是和執(zhí) 行的線程關(guān)聯(lián)的。

TransactionDefinition接口指定：

這些設(shè)置反映了標(biāo)準(zhǔn)概念。如果需要，請(qǐng)查閱討論事務(wù)隔離層次和其他核心事 務(wù)概念的資源：理解這些概念是使用Spring和其他事務(wù)管理解決方案的基本要素。

TransactionStatus接口為處理事務(wù)的代碼提供一個(gè)簡(jiǎn)單 的控制事務(wù)的執(zhí)行和查詢事務(wù)狀態(tài)方法。這個(gè)概念應(yīng)該是熟悉的，因?yàn)樗鼈冊(cè)谒?有的事務(wù)API中是相同的:

public interface TransactionStatus {

    boolean isNewTransaction();

    void setRollbackOnly();

    boolean isRollbackOnly();
}

但是使用Spring事務(wù)管理時(shí)，定義 PlatformTransactionManager的實(shí)現(xiàn)是基本方式。在好的Spring 風(fēng)格中，這個(gè)重要定義使用IoC實(shí)現(xiàn)。

PlatformTransactionManager實(shí)現(xiàn)通常需要了解它們工作 的環(huán)境：JDBC、JTA、Hibernate等等。

下面來(lái)自Spring范例jPetstore中的 dataAccessContext-local.xml的例子展示了一個(gè)局部 PlatformTransactionManager實(shí)現(xiàn)是如何定義的。它將和JDBC一起工作。

我們必須定義JDBC數(shù)據(jù)源，然后使用DataSourceTransactionManager，提供給 它的一個(gè)數(shù)據(jù)源引用。

<bean id="dataSource" 
    class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName"><value>${jdbc.driverClassName}</value></property>
    <property name="url"><value>${jdbc.url}</value></property>
    <property name="username"><value>${jdbc.username}</value></property>
    <property name="password"><value>${jdbc.password}</value></property>
</bean>

PlatformTransactionManager定義如下：

<bean id="transactionManager" 
    class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource"><ref local="dataSource"/></property>
</bean>

如果我們使用JTA，如同范例中dataAccessContext-jta.xml， 我們需要使用容器數(shù)據(jù)源，通過(guò)JNDI獲得，還需要一個(gè)JtaTransactionManager實(shí) 現(xiàn)，JtaTransactionManager不需要知道數(shù)據(jù)源，或任何其他指定資源，因?yàn)樗鼘?使用容器的全局事務(wù)管理。

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName"><value>jdbc/jpetstore</value></property>
</bean>

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>

我們可以很容易地使用Hibernate局部事務(wù)，如同下面Spring PetClinic 范例中的例子展現(xiàn)的一樣。

在這種情況下，我們需要定義一個(gè)Hibernate的LocalSessionFactory，應(yīng)用程 序?qū)⑹褂盟@得Hibernate Sessions。

數(shù)據(jù)源bean定義和上面例子類似，這里不在羅列（如果這是一個(gè)不需事務(wù)的容 器數(shù)據(jù)源，Spring而不是容器將管理事務(wù)）。

這種情況“transactionManager” bean的類型是HibernateTransactionManager。 和DataSourceTransactionManager擁有一個(gè)數(shù)據(jù)源的引用一樣， HibernateTransactionManager需要一個(gè) SessionFactory的引用。

<bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
    <property name="dataSource"><ref local="dataSource"/></property>
    <property name="mappingResources">
        <value>org/springframework/samples/petclinic/hibernate/petclinic.hbm.xml</value>
    </property>
    <property name="hibernateProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}</prop>
        </props>
    </property>
</bean>

<bean id="transactionManager" 
    class="org.springframework.orm.hibernate.HibernateTransactionManager">
    <property name="sessionFactory"><ref local="sessionFactory"/></property>
</bean>

使用Hibernate和JTA事務(wù)我們可以簡(jiǎn)單地使用JtaTransactionManager， 如同JDBC或任何其他資源策略。

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>

注意這是和任何其他使用JTA配置的其他資源一樣的，因?yàn)樗鼈兌际侨质聞?wù)。

如果不使用全局事務(wù)，你需要采用一個(gè)特定的代碼規(guī)范。幸運(yùn)的這是非常簡(jiǎn)單 的。你需要以一個(gè)特定的方式獲得連接或者session資源，允許相關(guān)的 PlatformTransactionManager實(shí)現(xiàn)跟蹤連接的使用，并且當(dāng)需要時(shí)應(yīng)用事務(wù)管理。

例如，如果使用JDBC，你不應(yīng)該調(diào)用一個(gè)數(shù)據(jù)源的 getConnection()方法，而必須使用Spring的 org.springframework.jdbc.datasource.DataSourceUtils類，如下:

Connection conn = DataSourceUtils.getConnection(dataSource);

這將提供額外的好處，任何SQLException都被Spring的 CannotGetJdbcConnectionException――Spring的不被檢查 的DataAccessException的類層次之一包裝起來(lái)。這給你比 簡(jiǎn)單地從SQLException獲得更多的信息，并且確保跨數(shù)據(jù) 庫(kù)，甚至跨越不同持久化技術(shù)的可移植性。

這將很好地在沒有Spring事務(wù)管理的情況下工作，因此無(wú)論使用還是不使用 Spring事務(wù)管理，你都可以使用它。

當(dāng)然，一旦你使用Spring JDBC支持或Hibernate支持，你將不必使用 DataSourceUtils或其他幫助類，因?yàn)槟銓⒈戎苯邮褂孟嚓P(guān) API更加愉快地使用Spring的抽象。例如，如果你使用Spring JdbcTemplate或 jdbc.object包來(lái)簡(jiǎn)化使用JDBC，正確的數(shù)據(jù)庫(kù)連接將自動(dòng)取得，你不需要書寫 任何特定代碼。

Spring提供兩種方式的編程式事務(wù)管理

我們通常推薦使用第一種方式。

第二種方式類似使用JTA UserTransaction API （雖然異常處理少一點(diǎn)麻煩）。

Object result = tt.execute(new TransactionCallback() {
    public Object doInTransaction(TransactionStatus status) {
        updateOperation1();
        return resultOfUpdateOperation2();
    }
});

tt.execute(new TransactionCallbackWithoutResult() {
    protected void doInTransactionWithoutResult(TransactionStatus status) {
        updateOperation1();
        updateOperation2();
    }
});

DefaultTransactionDefinition def = new DefaultTransactionDefinition()
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

TransactionStatus status = transactionManager.getTransactionDefinition(def);

try {
    // execute your business logic here
} catch (MyException ex) {
    transactionManager.rollback(status);
    throw ex;
}
transactionManager.commit(status);

Spring也提供了聲明式事務(wù)管理。這是通過(guò)Spring AOP實(shí)現(xiàn)的。

從考慮EJB CMT和Spring聲明式事務(wù)管理的相似以及不同之處出發(fā)是很有益的。 基本方法是一致的：都可以指定事務(wù)管理到單獨(dú)的方法；如果需要可以在事務(wù)上 下文調(diào)用setRollbackOnly()方法。不同之處：

回滾規(guī)則的概念是很重要的：它們使得我們可以指定那些異常應(yīng)該發(fā)起一個(gè)自 動(dòng)回滾。我們?cè)谂渲梦募卸皇荍ava代碼中指定這些聲明。因此，雖然我們?nèi)?然可以編程式調(diào)用TransactionStatus對(duì)象的 setRollbackOnly()方法來(lái)回滾當(dāng)前事務(wù)，多數(shù)時(shí)候我們可以 指定規(guī)則如MyApplicationException應(yīng)該用于導(dǎo)致一個(gè)回滾。 這有顯著的優(yōu)點(diǎn)，業(yè)務(wù)對(duì)象不需要依賴事務(wù)基礎(chǔ)設(shè)施。例如，他們通常不需要引 入任何Spring API,事務(wù)或其他任何東西。

EJB的默認(rèn)行為是遇到系統(tǒng)異常（通常是運(yùn)行時(shí)異常） EJB容器自動(dòng)回滾事務(wù)。EJB CMT遇到應(yīng)用程序異常 （除了java.rmi.RemoteException外被檢查的異常）時(shí)不 會(huì)自動(dòng)回滾事務(wù)。雖然Spring聲明式事務(wù)管理沿用EJB CMT約定（遇到不被檢查的 異常自動(dòng)回滾事務(wù)），但是這是可以定制的。

按照我們的基準(zhǔn)，Spring聲明式事務(wù)管理的性能要?jiǎng)龠^(guò)EJB CMT。

通常設(shè)置Spring事務(wù)代理的方法是通過(guò)TransactionProxyFactoryBean。我們需 要一個(gè)包裝在事務(wù)代理中目標(biāo)對(duì)象。這個(gè)目標(biāo)對(duì)象一般是一個(gè)POJO的bean。當(dāng)我 們定義TransactionProxyFactoryBean時(shí)，必須提供一個(gè)相關(guān)的 PlatformTransactionManager的引用和事務(wù)屬性。 事務(wù)屬性含有上面描述的事務(wù)定義。

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

事務(wù)代理會(huì)實(shí)現(xiàn)目標(biāo)對(duì)象的接口：這里是id為petStoreTarget.的bean（使用 CGLIB可以實(shí)現(xiàn)具體類的代理，只要設(shè)置proxyTargetClass屬性為true就可以。這 將自動(dòng)設(shè)置，如果目標(biāo)對(duì)象沒有實(shí)現(xiàn)任何接口。通常，我們希望面向接口而不是 類編程）。可以（一般來(lái)說(shuō)是好的想法）限定事務(wù)代理使用proxyInterfaces來(lái)代 理指定的接口。也可以通過(guò)繼承至 org.springframework.aop.framework.ProxyConfig幾個(gè)屬 性來(lái)定制TransactionProxyFactoryBean的行為，并在所有的AOP代理工廠中共享。

這里的transactionAttributes通過(guò)定在 org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource 類中的屬性格式來(lái)設(shè)置。這個(gè)包括通配符的方法名稱映射是很直觀的。注意 insert*的映射的值包括回滾規(guī)則。添加-MyCheckedException 指定如果方法拋出MyCheckedException或它的子類，事務(wù)將 會(huì)自動(dòng)回滾?？梢灾付▊€(gè)回滾規(guī)則，用逗號(hào)分隔。-前綴強(qiáng)制回滾，+前綴指定提 交（這允許即使拋出未被檢查的異常時(shí)也可以提交事務(wù)，當(dāng)然你自己要明白自己 在做什么）。

TransactionProxyFactoryBean允許你通過(guò) “preInterceptors”和“postInterceptors”屬性設(shè)置“前”或“后”通知來(lái)提供額外的 攔截行為。可以設(shè)置任意數(shù)量的“前”和“后”通知，它們的類型可以是 Advisor（可以包含一個(gè)pointcut）， MethodInterceptor或被當(dāng)前Spring配置支持的通知類型 （例如ThrowAdvice， AfterReturningtAdvice或BeforeAdvice， 這些都是默認(rèn)支持的）。這些通知必須支持實(shí)例共享模式。如果你需要高級(jí)AOP特 性來(lái)使用事務(wù)，如有狀態(tài)的混入，那最好使用通用的 org.springframework.aop.framework.ProxyFactoryBean， 而不是TransactionProxyFactoryBean代理創(chuàng)建者。

也可以設(shè)置自動(dòng)代理：配置AOP框架，不需要單獨(dú)的代理定義類就可以生成類的 代理。

更多信息和實(shí)例請(qǐng)參閱AOP章節(jié)。

7.4.1. BeanNameAutoProxyCreator，另一種聲明方式

TransactionProxyFactoryBean非常有用，并且當(dāng)事 務(wù)代理包裝對(duì)象時(shí)，你有全部的支配權(quán)。如果你需要用一致的方式（例如，一個(gè) 樣板文件，“使所有的方法事務(wù)化”）包裝大量的bean，使用一個(gè) BeanFactoryPostProcessor調(diào)用 BeanNameAutoProxyCreator可以提供另外一種方法， 一個(gè)在這種簡(jiǎn)單的情況下更加簡(jiǎn)化的方法。

重述一下，一旦ApplicationContext讀完它的初始化信息，它將初始化所有實(shí) 現(xiàn)BeanPostProcessor的bean，并且給所有其他 ApplicationContext中beans一個(gè)后期處理的機(jī)會(huì)。所以使用這種機(jī)制，一個(gè)正 確配置的BeanNameAutoProxyCreator可以用來(lái)后期處 理所有ApplicationContext中所有其他的bean（通過(guò)名稱來(lái)識(shí)別），并且把他 們用事務(wù)代理包裝起來(lái)。真正事務(wù)代理的生成和使用 TransactionProxyFactoryBean基本一致，這里不再 討論。

讓我們看下面的配置示例：

  <!-- Transaction Interceptor set up to do PROPOGATION_REQUIRED on all methods -->
  <bean id="matchAllWithPropReq" 
      class="org.springframework.transaction.interceptor.MatchAlwaysTransactionAttributeSource">
    <property name="transactionAttribute"><value>PROPAGATION_REQUIRED</value></property>
  </bean>
  <bean id="matchAllTxInterceptor" 
      class="org.springframework.transaction.interceptor.TransactionInterceptor">
    <property name="transactionManager"><ref bean="transactionManager"/></property>
    <property name="transactionAttributeSource"><ref bean="matchAllWithPropReq"/></property>
  </bean>

  <!-- One BeanNameAutoProxyCreator handles all beans where we want all methods to use 
       PROPOGATION_REQUIRED -->
  <bean id="autoProxyCreator" 
      class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="interceptorNames">
      <list>
        <idref local="matchAllTxInterceptor"/>
        <idref bean="hibInterceptor"/>
      </list>
    </property>
    <property name="beanNames">
      <list>
        <idref local="core-services-applicationControllerSevice"/>
        <idref local="core-services-deviceService"/>
        <idref local="core-services-authenticationService"/>
        <idref local="core-services-packagingMessageHandler"/>
        <idref local="core-services-sendEmail"/>
        <idref local="core-services-userService"/>
      </list>
    </property>
  </bean>

假設(shè)我們已經(jīng)有一個(gè)TransactionManager的實(shí)例 在ApplicationContext中，我們首先要做的使創(chuàng)建一個(gè) TransactionInterceptor實(shí)例。 ransactionInterceptor基于一個(gè)實(shí)現(xiàn) TransactionAttributeSource接口的對(duì)象決定哪個(gè) 方法被攔截, 這個(gè)對(duì)象作為屬性傳遞進(jìn)來(lái)的。這個(gè)例子中，我們希望處理匹配 所有方法這種最簡(jiǎn)單的情況。這個(gè)不是最有效的方式，但設(shè)置非常迅速，因?yàn)?我可以使用預(yù)先定義的匹配所有方法的 MatchAlwaysTransactionAttributeSource類。如果我 們需要特定的方式，可以使用 MethodMapTransactionAttributeSource， NameMatchTransactionAttributeSource或 AttributesTransactionAttributeSource。

現(xiàn)在我們已經(jīng)有了事務(wù)攔截器，我們只需把它和另外6個(gè)我們希望以一致方式 包裝的AppliactonContext中的bean一起放到我們定義的 BeanNameAutoProxyCreator實(shí)例中。你可以看到，這 個(gè)結(jié)果比用TransactionProxyFactoryBean以一種方式單獨(dú)包裝6個(gè)bean簡(jiǎn)捷很 多。包裝第7個(gè)bean只需添加一行配置。

你也許注意到可以應(yīng)用多個(gè)攔截器。在這個(gè)例子中，我們也可以應(yīng)用一個(gè)預(yù) 先定義的HibernateInterceptor （bean id=hibInterceptor），這個(gè)為我們管理 Hibernare的Sessions。

有一件事值得注意，就是在TransactionProxyFactoryBean, 和BeanNameAutoProxyCreator切換時(shí)bean的名稱。 第一種情況，你只需給你想要包裝的bean一個(gè)類似 myServiceTarget的id， 給代理對(duì)象一個(gè)類似myService的id， 然后所有代理對(duì)象的用戶只需引用代理對(duì)象， 如myService（這些是通用命名規(guī)范， 要點(diǎn)是目標(biāo)對(duì)象要有和代理對(duì)象不同的名稱， 并且他們都要在ApplicationContext中可用）。然而， 使用BeanNameAutoProxyCreator時(shí)， 你命名目標(biāo)對(duì)象為myService。 然后當(dāng)BeanNameAutoProxyCreator后期處理目標(biāo)對(duì)象 并生成代理時(shí)，它導(dǎo)致代理以和原始對(duì)象相同的名稱被插入到 ApplicationContext中。從這一點(diǎn)看，只有代理（含有被包裝的對(duì)象）在Application中可用。

如果你只有很少的事務(wù)操作，使用編程式事務(wù)管理是很好的主意。例如， 如果你有一個(gè)WEB應(yīng)用需要為某些更新操作提供事務(wù)，你可能不想用Spring或其 他技術(shù)設(shè)置一個(gè)事務(wù)代理。使用 TransactionTemplate可能是個(gè)很好的方法。

另一方面，如果你的應(yīng)用有大量的事務(wù)操作，編程式（譯注：應(yīng)為聲明式， 疑是作者筆誤）事務(wù)管理通常是很有價(jià)值的。它使得事務(wù)管理從業(yè)務(wù)邏輯分離， 并且Spring中配置也不困難。使用Spring， 而不是EJB CMT，聲明式事務(wù)管理配置的成本極大地降低。

Spring的事務(wù)管理能力――尤其聲明式事務(wù)管理極大地改變了J2EE應(yīng)用程序需要 應(yīng)用服務(wù)器的傳統(tǒng)想法。

特別地，你不需要應(yīng)用服務(wù)器僅僅為了通過(guò)EJB聲明事務(wù)。事實(shí)上，即使你擁 有強(qiáng)大JTA支持的應(yīng)用服務(wù)器，你也可以決定使用Spring聲明式事務(wù)管理提供比 EJB CMT更強(qiáng)大更高效的編程模型。

只有需要支持多個(gè)事務(wù)資源時(shí)你才需要應(yīng)用服務(wù)器的JTA支持。許多應(yīng)用沒有 這個(gè)需求。例如許多高端應(yīng)用使用單一的高度可升級(jí)的數(shù)據(jù)庫(kù)，如Oracle 9i RAC。

當(dāng)然也許你需要其他應(yīng)用服務(wù)器的功能，如JMS和JCA。但是如果你只需使用 JTA，你可以考慮開源的JTA實(shí)現(xiàn)，如JOTM（Spring整合了JOTM）。但是， 2004年早期，高端的應(yīng)用服務(wù)器提供更健壯的XA資源支持。

最重要一點(diǎn)，使用Spring，你可以選擇何時(shí)將你的應(yīng)用遷移到完整 應(yīng)用服務(wù)器。除了使用EJB CMT和JTA只能書寫代碼使用局部事務(wù)， 例如JDBC連接的事務(wù)，而且如果曾經(jīng)需要全局的容器管理的事務(wù)，還面臨著繁重 的改寫過(guò)程，這些日子一去不復(fù)返了。使用Spring只有配置需要改變，你的代碼 不需要。

開發(fā)著需要按照需求仔細(xì)的使用正確的 PlatformTransactionManager實(shí)現(xiàn)。

理解Spring事務(wù)抽象時(shí)如何和JTA全局事務(wù)一起工作是非常重要的。使用得當(dāng)， 沒有任何沖突：Spring僅僅提供一個(gè)簡(jiǎn)單的，可以移植的抽象層。

如果你使用全局事務(wù)，你必須為你的所有事務(wù)操作使用Spring的 org.springframework.transaction.jta.JtaTransactionManager。 否則Spring將試圖在資源如容器數(shù)據(jù)源執(zhí)行局部事務(wù)。這樣的局部事務(wù)沒有任何 意義，好的應(yīng)用服務(wù)器會(huì)把這作為一個(gè)錯(cuò)誤。