One of the most compelling reasons to use Spring is the transaction support. Spring provides a consistent abstraction for transaction management that delivers the following benefits: 一个使用Spring的引人注目的因素是事务支持。 Spring提供了一致的事务管理抽象，这带来了以下好处：

This chapter is divided up into a number of sections; these sections are described below, along with a link so that you can navigate directly to the section which interests you. 这章被分成几个小节，每节的描述和链接列在下面，你可以直接跳到感兴趣的部分。

The chapter closes up with some discussion of best practices surrounding transaction management (for example, choosing between declarative and programmatic transaction management). 本章末尾讨论了一些关于事务管理的最佳实践（比如，如何在编程式和声明式事务管理之间做选择）。

Traditionally, J2EE developers have had two choices for transaction management: global or local transactions. Global transactions are managed by the application server, using the Java Transaction API (JTA). Local transactions are resource-specific: the most common example would be a transaction associated with a JDBC connection. This choice has profound implications. For instance, global transactions provide the ability to work with multiple transactional resources (typically relational databases and message queues). With local transactions, the application server is not involved in transaction management and cannot help ensure correctness across multiple resources. (It is worth noting that most applications use a single transaction resource.) 传统上，J2EE开发者有两个事务管理的选择: 全局或 局部事务。全局事务由应用服务器管理，使用JTA。局部事务是和资源相关的：例如， 一个和JDBC连接关联的事务。这个选择有深刻的含义。例如，全局事务可以用于多个事务性的资源 （典型例子是关系数据库和消息队列）。使用局部事务，应用服务器不需要参与事务管理，并且不 能帮助确保跨越多个资源（需要指出的是多数应用使用单一事务性的资源）的事务的正确性。

Global Transactions 全局事务. Global transactions have a significant downside, in that code needs to use JTA, and JTA is a cumbersome API to use (partly due to its exception model). Furthermore, a JTA UserTransaction normally needs to be sourced from JNDI: meaning that we need to use both JNDI and JTA to use JTA. Obviously all use of global transactions limits the reusability of application code, as JTA is normally only available in an application server environment. 全局事务有一个重大的缺陷，代码需要使用JTA：一个笨重的API（部分是因为它的异常模型）。 此外，JTA的UserTransaction通常需要从JNDI获得，这意味着 我们为了JTA，需要 同时 使用JNDI 和 JTA。 显然全部使用全局事务限制了应用代码的重用性，因为JTA通常只在应用服务器的环境中才能使用。 Previously, the preferred way to use global transactions was via EJB CMT (Container Managed Transaction): CMT is a form of declarative transaction management (as distinguished from programmatic transaction management). EJB CMT removes the need for transaction-related JNDI lookups - although of course the use of EJB itself necessitates the use of JNDI. It removes most of the need (although not entirely) to write Java code to control transactions. The significant downside is that CMT is tied to JTA and an application server environment. Also, it is only available if one chooses to implement business logic in EJBs, or at least behind a transactional EJB facade. The negatives around EJB in general are so great that this is not an attractive proposition, especially in the face of compelling alternatives for declarative transaction management. 以前，使用全局事务的首选方式是通过EJB的 CMT（容器管理事务）： CMT是声明式事务管理的一种形式（区别于编程式事务管理）。 EJB的CMT不需要任何和事务相关的JNDI查找，虽然使用EJB本身肯定需要使用JNDI。它消除大多数（不是全部）书写Java代码去控制事务。 重大的缺陷是CMT绑定在JTA和应用服务器环境上，并且只有我们选择使用EJB实现业务逻辑，或者至少处于一个事务化EJB的外观（Facade） 后才能使用它。EJB有如此多的诟病，尤其是存在其它声明式事务管理时，EJB不是一个吸引人的建议。

Local Transactions 局部事务. Local transactions may be easier to use, but have significant disadvantages: they cannot work across multiple transactional resources. For example, code that manages transactions using a JDBC connection cannot run within a global JTA transaction. Another downside is that local transactions tend to be invasive of the programming model. 局部事务容易使用，但也有明显的缺点：它们不能用于多个事务性资源。 例如，使用JDBC连接事务管理的代码不能用于全局的JTA事务中。 另一个缺点是局部事务趋向于入侵式的编程模型

Spring resolves these problems. It enables application developers to use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction management strategies in different environments. Spring provides both declarative and programmatic transaction management. Declarative transaction management is preferred by most users, and is recommended in most cases. Spring解决了这些问题。它使应用开发者能够使用在任何环境 下使用一致的编程模型。你可以只写一次你的代码，这在不同环境 下的不同事务管理策略中很有益处。Spring同时提供声明式和编程式事务管理。 声明事务管理是多数使用者的首选，在多数情况下是被推荐使用的。

With programmatic transaction management, developers work with the Spring transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model, developers typically write little or no code related to transaction management, and hence don't depend on Spring's transaction API (or indeed on any other transaction API). 使用编程式事务管理，开发者直接使用Spring事务抽象，这个抽象可以使用在任何 底层事务基础之上。使用首选的声明式模型，开发者通常书写很少的或没有与事务 相关的代码，因此不依赖Spring或任何其他事务API。

The key to the Spring transaction abstraction is the notion of a transaction strategy. A transaction strategy is defined by the org.springframework.transaction.PlatformTransactionManager interface, shown below: 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;
}

This is primarily an SPI interface, although it can be used programmatically. Note that in keeping with Spring's philosophy, PlatformTransactionManager is an interface, and can thus be easily mocked or stubbed as necessary. Nor is it tied to a lookup strategy such as JNDI: PlatformTransactionManager implementations are defined like any other object (or bean) in a Spring IoC container. This benefit alone makes it a worthwhile abstraction even when working with JTA: transactional code can be tested much more easily than if it used JTA directly. 这首先是一个SPI接口，虽然它也可以在 编码中使用。注意按照Spring的哲学，PlatformTransactionManager 是一个接口。因而如果需要它可以很容易地被模拟和 桩化。它也没有和一个查找策略如JNDI捆绑在一起：PlatformTransactionManager 的实现定义和其他Spring IoC容器中的对象一样。这个好处使得即使使用JTA，也 是一个很有价值的抽象：事务代码可以比直接使用JTA更加容易测试。

Again in keeping with Spring's philosophy, the TransactionException that can be thrown by any of the PlatformTransactionManager interface's methods is unchecked (i.e. it extends the java.lang.RuntimeException class). Transaction infrastructure failures are almost invariably fatal. In rare cases where application code can actually recover from a transaction failure, the application developer can still choose to catch and handle TransactionException. The salient point is that developers are not forced to do so. 继续Spring哲学，可由任何PlatformTransactionManager的接口方法抛出的 TransactionException是unchecked(继承自 java.lang.RuntimeException)的。 底层的事务失败几乎总是致命的。很少情况下应用程序代码可以从它们 中恢复，不过应用开发者依然可以捕获并处理 TransactionException，他们可以自由决定怎么干。

The getTransaction()method returns a TransactionStatus object, depending on a TransactionDefinition parameter. The returned TransactionStatus might represent a new or existing transaction (if there were a matching transaction in the current call stack - with the implication being that (as with J2EE transaction contexts) a TransactionStatus is associated with a thread of execution). getTransaction()方法根据一个类型为 TransactionDefinition的参数返回一个 TransactionStatus对象。返回的 TransactionStatus对象可能代表一个新的或已经存在的事 务（如果在当前调用堆栈有一个符合条件的事务。如同J2EE事务环境，一个 TransactionStatus也是和 执行线程关联的）。

The TransactionDefinition interface specifies: TransactionDefinition接口指定：

These settings reflect standard transactional concepts. If necessary, please refer to a resource discussing transaction isolation levels and other core transaction concepts: understanding such core concepts is essential to using Spring or indeed any other transaction management solution. 这些设置反映了标准概念。如果需要，请查阅讨论事务隔离层次和其他核心事务概念的资源： 理解这些概念在使用Spring和其他事务管理解决方案时是非常关键的。

The TransactionStatus interface provides a simple way for transactional code to control transaction execution and query transaction status. The concepts should be familiar, as they are common to all transaction APIs: TransactionStatus 接口为处理事务的代码提供一个简单的控制事务执行和查询事务状态的方法。 这个概念应该是熟悉的，因为它们在所有的事务API中是相同的:

public interface TransactionStatus {

    boolean isNewTransaction();

    void setRollbackOnly();

    boolean isRollbackOnly();
}

Regardless of whether you opt for declarative or programmatic transaction management in Spring, defining the correct PlatformTransactionManager implementation is absolutely essential. In good Spring fashion, this important definition typically is made using IoC. 使用Spring时，无论你选择编程式还是声明式的事务管理，定义一个正确的 PlatformTransactionManager 实现都是至关重要的。 按照Spring的风格，这种重要定义都是通过IoC实现的。

PlatformTransactionManager implementations normally require knowledge of the environment in which they work: JDBC, JTA, Hibernate, etc The following examples from the dataAccessContext-local.xml file from Spring's jPetStore sample application show how a local PlatformTransactionManager implementation can be defined. (This will work with plain JDBC.) 一般来说，选择PlatformTransactionManager实现时需要知道 当前的工作环境，如JDBC、JTA、Hibernate等。下面的例子来自Spring范例应用—— jPetStore——中的dataAccessContext-local.xml文件，其中 展示了一个局部PlatformTransactionManager实现是怎么定义 的（仅限于纯粹JDBC环境）

We must define a JDBC DataSource, and then use the Spring DataSourceTransactionManager, giving it a reference to the DataSource. 我们必须先定义一个JDBC DataSource，然后使用Spring DataSourceTransactionManager，并传入指向 DataSource的引用。

The related PlatformTransactionManager bean definition will look like this: PlatformTransactionManager bean的定义如下：

If we use JTA, as in the dataAccessContext-jta.xml file from the same sample application, we need to use a container DataSource, obtained via JNDI, and a JtaTransactionManager implementation. The JtaTransactionManager doesn't need to know about the DataSource, or any other specific resources, as it will use the container's global transaction management infrastructure. 如果我们使用JTA，就像范例中dataAccessContext-jta.xml文件所示， 我们将从JNDI中获取一个容器管理的DataSource，以及一个 JtaTransactionManager实现。 JtaTransactionManager不需要知道 DataSource和其他特定的资源，因为它将使用容器提供的全局事务管理。

Note

The above definition of the 'dataSource' bean uses the 'jndi-lookup' tag from the 'jee' namespace. For more information on schema-based configuration, see Appendix A, XML Schema-based configuration, and for more information on the tags see the section entitled Section A.2.3, “The jee schema”. 上面'dataSource' bean的定义使用了'jee' 名称空间下的'jndi-lookup'标签。想了解更多的配置信息, 请看 Appendix A, XML Schema-based configuration， 关于标签的信息，可参考Section A.2.3, “The jee schema”节。

We can use Hibernate local transactions easily, as shown in the following examples from the Spring PetClinic sample application. In this case, we need to define a Hibernate LocalSessionFactoryBean, which application code will use to obtain Hibernate Session instances. 我们可以很容易地使用Hibernate局部事务，就像下面的Spring的PetClinic示例应用中的例子一样）。 这种情况下，我们需要定义一个Hibernate的LocalSessionFactoryBean， 应用程序从中获取到Hibernate Session 实例。

The DataSource bean definition will be similar to one of the above examples, and is not shown. (If it is a container DataSource, it should be non-transactional as Spring, rather than the container, will manage transactions.) DataSource bean的定义同上例类似，这里不再展示。 （不过，如果是一个容器提供的DataSource， 它将由容器自身，而不是Spring，来管理事务）。

The 'txManager' bean in this case is of class HibernateTransactionManager. In the same way as the DataSourceTransactionManager needs a reference to the DataSource, the HibernateTransactionManager needs a reference to the SessionFactory. 这种情况中'txManager' bean的类型为HibernateTransactionManager。 同样地，DataSourceTransactionManager需要一个指向 DataSource的引用，而 HibernateTransactionManager需要一个指向 SessionFactory的引用。

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



  

With Hibernate and JTA transactions, we can simply use the JtaTransactionManager as with JDBC or any other resource strategy. 我们可以简单地使用JtaTransactionManager来处理Hibernate事务和JTA事务， 就像我们处理JDBC，或者任何其它的资源策略一样。

Note that this is identical to JTA configuration for any resource, as these are global transactions, which can enlist any transactional resource. 注意任何资源的JTA配置都是这样的，因为它们都是全局事务，可以支持任何事务性资源。

In all these cases, application code won't need to change at all. We can change how transactions are managed merely by changing configuration, even if that change means moving from local to global transactions or vice versa. 在所有这些情况下，应用程序代码根本不需要做任何改动。我们仅仅通过改变配置就可以改变事务如何被管理， 即使这些更改意味着在局部事务和全局事务间切换。

It should now be clear how different transaction managers are created, and how they are linked to related resources which need to be synchronized to transactions (i.e. DataSourceTransactionManager to a JDBC DataSource, HibernateTransactionManager to a Hibernate SessionFactory, etc). There remains the question however of how the application code, directly or indirectly using a persistence API (JDBC, Hibernate, JDO, etc), ensures that these resources are obtained and handled properly in terms of proper creation/reuse/cleanup and trigger (optionally) transaction synchronization via the relevant PlatformTransactionManager. 现在应该比较清楚了，不同的事务管理器是如何创建的，以及它们如何被连接到相应的 需要被同步到事务的资源上（例如，DataSourceTransactionManager 对应到JDBC DataSource， HibernateTransactionManager对应到Hibernate SessionFactory等）。可是，剩下的问题是， 直接或间接地使用一种持久化API（JDBC，Hibernate，JDO等）的应用代码，如何确保通过 相关的PlatformTransactionManager来恰当地 获取并操作资源，来满足事务同步（包括：创建/复用/清理 和 触发（可能没有））。

            Connection conn = DataSourceUtils.getConnection(dataSource);

Spring's declarative transaction management is made possible with Spring AOP, although, as the transactional aspects code comes with Spring and may be used in a boilerplate fashion, AOP concepts do not generally have to be understood to make effective use of this code. Spring的声明式事务管理是通过Spring AOP实现的，因为事务方面的代码与Spring绑定并 以一种样板式风格使用，不过尽管如此，你一般并不需要理解AOP概念就可以有效地使用 Spirng的声明式事务管理。

It may be helpful to begin by considering EJB CMT and explaining the similarities and differences with Spring declarative transaction management. The basic approach is similar: it is possible to specify transaction behavior (or lack of it) down to individual method level. It is possible to make a setRollbackOnly() call within a transaction context if necessary. The differences are: 从考虑EJB CMT和Spring声明式事务管理的相似以及不同之处出发是很有益的。 它们的基本方法是相似的：都可以指定事务管理到单独的方法；如果需要可以在事务上下文调用 setRollbackOnly()方法。不同之处如下：

The concept of rollback rules is important: they enable us to specify which exceptions (and throwables) should cause automatic roll back. We specify this declaratively, in configuration, not in Java code. So, while we can still call setRollbackOnly() on the TransactionStatus object to roll the current transaction back programmatically, most often we can specify a rule that MyApplicationException should always result in roll back. This has the significant advantage that business objects don't need to depend on the transaction infrastructure. For example, they typically don't need to import any Spring APIs, transaction or other. 回滚规则的概念比较重要：它使我们能够指定什么样的异常(和throwables)将导致自动回滚。 我们在配置文件中声明式地指定，无须在Java代码中。同时，我们仍旧可以通过调用 TransactionStatus的setRollbackOnly() 方法编程式地回滚当前事务。通常，我们定义一条规则，声明 MyApplicationException应该总是导致事务回滚。这种方式 带来了显著的好处，它使你的业务对象不必依赖于事务设施。典型的例子是你不必在代码中导入Spring API，事务等。

While the EJB default behavior is for the EJB container to automatically roll back the transaction on a system exception (usually a runtime exception), EJB CMT does not roll back the transaction automatically on an application exception (i.e. a checked exception other than java.rmi.RemoteException). While the Spring default behavior for declarative transaction management follows EJB convention (roll back is automatic only on unchecked exceptions), it's often useful to customize this. 对EJB来说，默认的行为是EJB容器在遇到系统异常（通常指运行时异常）时自动回滚当前事务。 EJB CMT遇到应用异常（例如，除了java.rmi.RemoteException外别的checked exception）时 并不会自动回滚。默认式Spring处理声明式事务管理的规则遵守EJB习惯（只在遇到unchecked exceptions时自动回滚）， 但通常定制这条规则会更有用。

9.5.1. Understanding Spring's declarative transaction implementation 理解Spring的声明式事务管理实现

The aim of this section is to dispel the mystique that is sometimes associated with the use of declarative transactions. It is all very well for this reference documentation simply to tell you to annotate your classes with the @Transactional annotation, add the line ('') to your configuration, and then expect you to understand how it all works. This section will explain the inner workings of Spring's declarative transaction infrastructure to help you navigate your way back upstream to calmer waters in the event of transaction-related issues. 本节的目的是消除与使用声明式事务管理有关的神秘性。简单点儿总是好的，这份参考文档 只是告诉你给你的类加上@Transactional注解， 在配置文件中添加（''）行， 然后期望你理解整个过程是怎么工作的。此节讲述Spring的声明式事务管理内部的工作机制， 以帮助你在面对事务相关的问题时不至于误入迷途，回朔到上游平静的水域。

Tip

Looking at the Spring source code is a good way to get a real understanding of Spring's transaction support. You should find the Javadoc informative and complete. We suggest turning the logging level to 'DEBUG' in your Spring-enabled application(s) during development to better see what goes on under the hood. 阅读Spring源码是理解清楚Spring事务支持的一个好方法。Spring的Javadoc提供的信息丰富而完整。 我们建议你在开发自己的Spring应用时把日志级别设为'DEBUG'级，这样你能更清楚地看到幕后发生的事。

The most important concepts to grasp with regard to Spring's declarative transaction support are that this support is enabled via AOP proxies, and that the transactional advice is driven by metadata (currently XML- or annotation-based). The combination of a proxy with transactional metadata yields an AOP proxy that uses a TransactionInterceptor in conjunction with an appropriate PlatformTransactionManager implementation to drive transactions around method invocations. 在理解Spring的声明式事务管理方面最重要的概念是：Spring的事务管理是通过 AOP代理实现的。其中的事务通知由元数据 （目前基于XML或注解）驱动。代理对象与事务元数据结合产生了一个AOP代理，它使用 一个PlatformTransactionManager实现品配合 TransactionInterceptor，在方法调用 前后实施事务。

Note

Although knowledge of AOP (and specifically Spring AOP) is not required in order to use Springs declarative transaction support, it can help. Spring AOP is thoroughly covered in the chapter entitled Chapter 6, Aspect Oriented Programming with Spring 使用Spring进行面向切面编程(AOP). 尽管使用Spring声明式事务管理不需要AOP（尤其是Spring AOP）的知识，但了解这些是很有帮助的。 你可以在Chapter 6, Aspect Oriented Programming with Spring 使用Spring进行面向切面编程(AOP)章找到关于Spring AOP的全部内容。

Conceptually, calling a method on a transactional proxy looks like this... 概念上来说，在事务代理上调用方法的工作过程看起来像这样：

 
            
            
            

package x.y.service;

public interface FooService {

    Foo getFoo(String fooName);

    Foo getFoo(String fooName, String barName);

    void insertFoo(Foo foo);

    void updateFoo(Foo foo);
}

 
            上面接口的实现
            
            

package x.y.service;

public class DefaultFooService implements FooService {

    public Foo getFoo(String fooName) {
        throw new UnsupportedOperationException();
    }

    public Foo getFoo(String fooName, String barName) {
        throw new UnsupportedOperationException();
    }

    public void insertFoo(Foo foo) {
        throw new UnsupportedOperationException();
    }

    public void updateFoo(Foo foo) {
        throw new UnsupportedOperationException();
    }
}

 
            
            
            


       xmlns:tx="http://www.springframework.org/schema/tx"
       
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       
       
       http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
       
       
       http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd">

  
  <!-- this is the service o