Spring提供了一致的事务管理抽象。这个抽象是Spring最重要的抽象之一， 它有如下的优点：

传统上，J2EE开发者有两个事务管理的选择: 全局事务或 局部事务。全局事务由应用服务器管理，使用JTA。局部 事务是和资源相关的：例如，一个和JDBC连接关联的事务。这个选择有深刻的含义。 全局事务可以用于多个事务性的资源（需要指出的是多数应用使用单一事务性 的资源）。使用局部事务，应用服务器不需要参与事务管理，并且不能帮助确保 跨越多个资源的事务的正确性。

全局事务有一个显著的不利方面，代码需要使用JTA：一个笨重的API（部分是 因为它的异常模型）。此外，JTA的UserTransaction通常需 要从JNDI获得，这意味着我为了JTA需要同时使用JNDI和JTA。 显然全部使用全局事务限制了应用代码的重用性，因为JTA通常只在应用服 务器的环境中才能使用。

使用全局事务的比较好的方法是通过EJB的CMT （容器管理的事务）： 声明式事务管理的一种形式（区别于编程式事务管理 ）。EJB的CMT不需要任何和事务相关的JNDI查找，虽然使用EJB本身 肯定需要使用JNDI。它消除大多数——不是全部——书写Java代码控制事务的需求。 显著的缺点是CMT绑定在JTA和应用服务器环境上，并且只有我们选择 使用EJB实现业务逻辑，或者至少处于一个事务化EJB的外观（Facade）后 才能使用它。EJB有如此多的诟病，当存在其它声明式事务管理时， EJB不是一个吸引人的建议。

局部事务容易使用，但也有明显的缺点：它们不能用于多个事务性资 源，并且趋向侵入的编程模型。例如，使用JDBC连接事务管理的代码不能用于 全局的JTA事务中。

Spring解决了这些问题。它使应用开发者能够使用在任何环境 下使用一致的编程模型。你可以只写一次你的代码，这在不同环境 下的不同事务管理策略中很有益处。Spring同时提供声明式和编程式事务管理。

使用编程式事务管理，开发者直接使用Spring事务抽象，这个抽象可以使用在任何 底层事务基础之上。使用首选的声明式模型，开发者通常书写很少的事务相关代 码，因此不依赖Spring或任何其他事务API。

Spring事务抽象的关键是事务策略的概念。

这个概念由 org.springframework.transaction.PlatformTransactionManager 接口体现，如下：

public interface PlatformTransactionManager {    TransactionStatus getTransaction(TransactionDefinition definition)        throws TransactionException;    void commit(TransactionStatus status) throws TransactionException;    void rollback(TransactionStatus status) throws TransactionException;}

这首先是一个SPI接口，虽然它也可以在编码中使用。注意按照Spring的哲学， 这是一个接口。因而如果需要它可以很容易地被模拟和 桩化。它也没有和一个查找策略如JNDI捆绑在一起：PlatformTransactionManager 的实现定义和其他Spring IoC容器中的对象一样。这个好处使得即使使用JTA，也 是一个很有价值的抽象：事务代码可以比直接使用JTA更加容易测试。

继续Spring哲学，TransactionException是unchecked的。 低层的事务失败几乎都是致命。很少情况下应用程序代码可以从它们 中恢复，不过应用开发者依然可以捕获并处理 TransactionException。

getTransaction()根据一个类型为 TransactionDefinition的参数返回一个 TransactionStatus对象。返回的 TransactionStatus对象可能代表一个新的或已经存在的事 务（如果在当前调用堆栈有一个符合条件的事务）。

如同J2EE事务上下文一样，一个TransactionStatus也是和执 行的线程关联的。

TransactionDefinition接口指定：

这些设置反映了标准概念。如果需要，请查阅讨论事务隔离层次和其他核心事 务概念的资源：理解这些概念在使用Spring和其他事务管理解决方案时是非常关键的。

TransactionStatus接口为处理事务的代码提供一个简单 的控制事务执行和查询事务状态的方法。这个概念应该是熟悉的，因为它们在所 有的事务API中是相同的:

public interface TransactionStatus {    boolean isNewTransaction();    void setRollbackOnly();    boolean isRollbackOnly();}

但是使用Spring事务管理时，定义 PlatformTransactionManager的实现是基本方式。在好的Spring 风格中，这个重要定义使用IoC实现。

PlatformTransactionManager实现通常需要了解它们工作 的环境：JDBC、JTA、Hibernate等等。

下面来自Spring范例jPetstore中的 dataAccessContext-local.xml，它展示了一个局部 PlatformTransactionManager实现是如何定义的。它将和JDBC一起工作。

我们必须定义JDBC数据源，然后使用DataSourceTransactionManager，提供给 它的一个数据源引用。

        
     
      
       ${jdbc.driverClassName}
      
         
     
      
       ${jdbc.url}
      
         
     
      
       ${jdbc.username}
      
         
     
      
       ${jdbc.password}
      
     
    

PlatformTransactionManager定义如下：

如果我们使用JTA，如同范例中dataAccessContext-jta.xml， 我们需要使用通过JNDI获得的容器数据源，和一个JtaTransactionManager实 现。JtaTransactionManager不需要知道数据源，或任何其他特定资源，因为它将 使用容器的全局事务管理。

        
     
      
       jdbc/jpetstore
      
     
    
    

我们可以很容易地使用Hibernate局部事务，如同下面Spring的PetClinic 示例应用中的例子的一样。

在这种情况下，我们需要定义一个Hibernate的LocalSessionFactory，应用程 序将使用它获得Hibernate的会话。

数据源bean定义和上面例子类似，这里不再罗列（如果这是容器数据源，它应该是非事务的，因为Spring会管理事务， 而不是容器）。

这种情况下，“transactionManager” bean的类型是HibernateTransactionManager。 和DataSourceTransactionManager拥有一个数据源的引用一样， HibernateTransactionManager需要一个SessionFactory的引用。

        
     
      
         
             
      
       org/springframework/samples/petclinic/hibernate/petclinic.hbm.xml
          
         
             
                  
       
        ${hibernate.dialect}
               
          
     
    
        
     
      
     
    

使用Hibernate和JTA事务，我们可以简单地使用JtaTransactionManager， 就象JDBC或任何其他资源策略一样。

注意任何资源的JTA配置都是这样的，因为它们都是全局事务。

如果不使用全局事务，你需要采用一个特定的编码规范。幸运的是它非常简单 。你需要以一个特殊的方式获得连接资源或者会话资源，允许相关的 PlatformTransactionManager实现跟踪连接的使用，并且当需要时应用事务管理。

例如，如果使用JDBC，你不应该调用一个数据源的 getConnection()方法，而必须使用Spring的 org.springframework.jdbc.datasource.DataSourceUtils类，如下:

Connection conn = DataSourceUtils.getConnection(dataSource);

这将提供额外的好处，任何SQLException都被Spring的 CannotGetJdbcConnectionException封装起来，它属于Spring的unchecked 的DataAccessException的类层次。这给你比 简单地从SQLException获得更多的信息，并且确保跨数据 库，甚至跨越不同持久化技术的可移植性。

没有Spring事务管理的情况下，这也能很好地工作，因此无论使用 Spring事务管理与否，你都可以使用它。

当然，一旦你使用Spring的JDBC支持或Hibernate支持，你将不想使用 DataSourceUtils或其他帮助类，因为与直接使用相关API相比，你将更乐意使用Spring的抽象。 例如，如果你使用Spring的JdbcTemplate或jdbc.object包来简化使用JDBC， 正确的数据库连接将自动取得，你不需要书写任何特殊代码。

Spring提供两种方式的编程式事务管理

我们通常推荐使用第一种方式。

第二种方式类似使用JTA UserTransaction API （虽然异常处理少一点麻烦）。

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也提供了声明式事务管理。这是通过Spring AOP实现的。

从考虑EJB CMT和Spring声明式事务管理的相似以及不同之处出发是很有益的。 它们的基本方法是相似的：都可以指定事务管理到单独的方法；如果需要可以在事务上 下文调用setRollbackOnly()方法。不同之处如下：

回滚规则的概念是很重要的：它们使得我们可以指定哪些异常应该发起自 动回滚。我们在配置文件中，而不是Java代码中，以声明的方式指定。因此，虽然我们仍 然可以编程调用TransactionStatus对象的 setRollbackOnly()方法来回滚当前事务，多数时候我们可以 指定规则，如MyApplicationException应该导致回滚。 这有显著的优点，业务对象不需要依赖事务基础设施。例如，它们通常不需要引 入任何Spring API，事务或其他任何东西。

EJB的默认行为是遇到系统异常（通常是运行时异常）， EJB容器自动回滚事务。EJB CMT遇到应用程序异常 （除了java.rmi.RemoteException外的checked异常）时不 会自动回滚事务。虽然Spring声明式事务管理沿用EJB的约定（遇到unchecked 异常自动回滚事务），但是这是可以定制的。

按照我们的测试，Spring声明式事务管理的性能要胜过EJB CMT。

通常通过TransactionProxyFactoryBean设置Spring事务代理。我们需 要一个目标对象包装在事务代理中。这个目标对象一般是一个普通Java对象的bean。当我 们定义TransactionProxyFactoryBean时，必须提供一个相关的 PlatformTransactionManager的引用和事务属性。 事务属性含有上面描述的事务定义。

        
     
      
         
     
      
         
             
                  
       
        PROPAGATION_REQUIRED,-MyCheckedException
                   
       
        PROPAGATION_REQUIRED
                   
       
        PROPAGATION_REQUIRED,readOnly
               
          
     
    

事务代理会实现目标对象的接口：这里是id为petStoreTarget的bean。（使用 CGLIB也可以实现具体类的代理。只要设置proxyTargetClass属性为true就可以。 如果目标对象没有实现任何接口，这将自动设置该属性为true。通常，我们希望面向接口而不是 类编程。）使用proxyInterfaces属性来限定事务代理来代 理指定接口也是可以的（一般来说是个好想法）。也可以通过从 org.springframework.aop.framework.ProxyConfig继承或所有AOP代理工厂共享 的属性来定制TransactionProxyFactoryBean的行为。

这里的transactionAttributes属性定义在 org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource 中的属性格式来设置。这个包括通配符的方法名称映射是很直观的。注意 insert*的映射的值包括回滚规则。添加的-MyCheckedException 指定如果方法抛出MyCheckedException或它的子类，事务将 会自动回滚。可以用逗号分隔定义多个回滚规则。-前缀强制回滚，+前缀指定提 交（这允许即使抛出unchecked异常时也可以提交事务，当然你自己要明白自己 在做什么）。

TransactionProxyFactoryBean允许你通过 “preInterceptors”和“postInterceptors”属性设置“前”或“后”通知来提供额外的 拦截行为。可以设置任意数量的“前”和“后”通知，它们的类型可以是 Advisor（可以包含一个切入点）， MethodInterceptor或被当前Spring配置支持的通知类型 （例如ThrowAdvice， AfterReturningtAdvice或BeforeAdvice， 这些都是默认支持的）。这些通知必须支持实例共享模式。如果你需要高级AOP特 性来使用事务，如有状态的maxin，那最好使用通用的 org.springframework.aop.framework.ProxyFactoryBean， 而不是TransactionProxyFactoryBean实用代理创建者。

也可以设置自动代理：配置AOP框架，不需要单独的代理定义类就可以生成类的 代理。

更多信息和实例请参阅AOP章节。

       
         
      
       
        PROPAGATION_REQUIRED
       
        
       
         
      
       
          
      
       
        
       
       
         
            
               
                
              
           
          
            
               
                
                
                
                
                
              
           
        
     

如果你只有很少的事务操作，使用编程式事务管理才是个好主意。例如， 如果你有一个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将试图在象容器数据源这样的资源上执行局部事务。这样的局部事务没有任何 意义，好的应用服务器会把这作为一个错误。

from: http://docs.huihoo.com/spring/zh-cn/transaction.html