《Spring3实战》摘要（6）事务管理

第6章 事务管理

6.1 理解事务

在软件开发领域，全有或全无的操作被称为事务（transaction）。事务允许你将几个操作组合成一个要么全部发生要么全部不发生的工作单元。如果一切顺利，事务将会成功。但是有任何一件事情出错的话，所发生的行为将会被清除干净，就像什么事情都没有发生一样。

6.1.1 用4个词来表示事务

在传统的软件开发中，人们创建了一个术语来描述事务：ACID。简单来说，ACID 表示4个特性。

• 原子性（Atomic）：事务是由一个或多个活动所组成的一个工作单元。原子性确保事务中的所有操作全部发生或全部不发生。如果所有的活动都成功了，事务也成功了。如果任意一个活动失败了，整个事务也失败并回滚。
• 一致性（Consistent）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业务处于一致的状态 。现实的数据不应该被损坏。
• 隔离性（Isolated）：事务允许多个用户对相同的数据进行操作，每个用户的操作不会与其他用户纠缠在一起。因此，事务应该被彼此隔离，避免发生同步读写相同数据的事情（注意的是，隔离性往往涉及到锁定数据库中的行或表）。
• 持久性（Durable）：一旦事务完成，事务的结果应该持久化，这样就能从任何的系统崩溃中恢复过来。这一般涉及将结果存储到数据库或其他形式的持久化存储中。

6.1.2 理解 Spring 对事务管理的支持

如果你的应用程序只使用一种持久化资源，Spring 可以使用持久化机制本身所提供的事务性支持，这包括了 JDBC、Hibernate 以及 Java 持久化 API（JPA）。但是如果应用程序的事务跨多个资源，那么Spring会使用第三方的 JTA（Java 事务API，Java Transaction API）实现来支持分布式（XA）事务。

编码式事务允许用户在代码中精确定义事务的边界，而声明式事务（基于AOP）有助于用户将操作与事务规则进行解耦。

选择编码式事务还是声明式事务很大程度上式在细粒度控制和易用性之间进行权衡。当通过编码实现事务控制时，你能够精确控制事务的边界，它们的开始和结束完全取决于你的需求。通常，你不需要编码式事务所提供的细粒度控制，而会选择在上下文定义文件中声明事务。

6.2 选择事务管理器

Spring 并不直接管理事务，而是提供了多种事务管理器，它们将事务管理的职责委托给 JTA 或其他持久化机制所提供的平台相关的事务实现。

为了使用事务管理器，你需要将其声明在应用程序上下文中。

6.2.1 JDBC 事务

将 DataSourceTransactionManager 装配到应用程序上下文定义中：

<bean id="transactionManager"
    class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
            <!-- dataSource 属性为 javax.sql.DataSource Bean -->
            <property name="dataSource" ref="dataSource" />
</bean>

在幕后，DataSourceTransactionmanager 通过调用 Java.sql.Connection 来管理事务，而后者是通过 DataSource 获取到的。通过调用连接的 commit() 方法来提交事务。同样，事务失败时通过调用 rollback() 方法进行回滚。

6.2.2 Hibernate 事务

对于 Hibernate 3 ,需要在 Spring 上下文定义中添加如下的声明：

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

HibernateTransactionManager 将事务管理的职责委托给 org.hibernate.Transaction 对象，而后者是从 Hibernate Session 中获取到的。当事务成功完成时，HibernatetransactionManager 将会调用 Transaction 对象的 commit() 方法。类似地，如果事务失败，Transaction 对象的 rollback() 方法将会被调用。

6.2.3 Java持久化API事务（略）

6.3 在 Spring 中编码事务

参考Spring事务管理（2）–第五章 编程式事务管理

6.4 声明式事务

Spring 提供了3种方式来声明事务式边界。以前，Spring 只能使用 Spring AOP 和 TransactionProxyFactoryBean 的代理 Bean 来实现声明式事务。但是自从 Spring 2.0 ，声明事务的更高方式是使用 Spring 的 tx 命名空间和 @Transactional 注解。

在最新版本的 Spring 中，尽管遗留的 TransactionProxyFactoryBean 仍然可以使用，但它实际上已经被淘汰了。具体用法可参考Spring事务管理（2）–第六章 声明式事务管理

在本小节的后面，我们将会关注 tx 命名空间和以注解为主的声明式事务。

6.4.1 定义事务属性

在 Spring 中，声明式事务式通过事务属性（transaction attribute）来定义的。事务属性描述了事务策略如何应用到方法上。事务属性包括了5个方面：

• 传播行为（propagation behavior）
• 隔离级别（isolation level）
• 回滚规则
• 事务超时
• 是否只读

传播行为（propagation behavior）
传播行为定义了客户端与被调用方法之间的事务边界。Spring 定义了7种不同的传播行为。

传播行为都在 org.springframework.transaction.TransactionDefinition 接口中以常量的方式进行了定义。

传播行为	含义
PROPAGATION_MANDATORY	表示该方法必须在事务中运行，如果当前事务不存在，则会抛出一个异常
PROPAGATION_NESTED	表示如果当前已经存在一个事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在，那么其行为与PROPAGATION_REQUIRED一样。注意各厂商对这种传播行为的支持是有所差异的。可以参考资源管理器文档来确定它们是否支持嵌套式事务。
PROPAGATION_NEVER	表示当前方法不应该运行在事务上下文中。如果当前正有一个事务在运行，则抛出异常。
PROPAGATION_NOT_SUPPORTED	表示该方法不应该运行在事务中。如果存在当前事务，在该方法运行期间，当前事务将被挂起。如果使用 JTATransactionManager 的话，则需要访问 TransactionManager。
PROPAGATION_REQUIRED	表示当前方法必须运行在事务中。如果当前事务存在，方法将会在该事务中运行。否则，会启动一个新的事务。
PROPAGATION_REQUIRES_NEW	表示当前方法必须运行在它的事务中。一个新的事务将被启动。如果存在当前事务，在该方法执行期间，当前事务会被挂起，如果使用 JTATransactionManager，则需要访问 TransactionManager
PROPAGATION_SUPPORTS	表示当前方法不需要事务上下文，但是如果存在当前事务的话，那么该方法会在这个事务中运行。

隔离级别（isolation level）

隔离级别定义了一个事务可能受其他并发事务影响的程度。另一种考虑隔离级别的方式就是将其想想成事务对于事务性数据的自私程度。

隔离级别都在 org.springframework.transaction.TransactionDefintion 接口中以常量的方式进行了定义。

在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务。并发，虽然是必需的，但可能会导致一下问题：

• 脏读（Dirty reads）：脏读发生在一个事务读取了另一个事务改写但是尚未提交的数据时。如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。
• 不可重复读（Nonrepeatable read）：不可重复读发生在一个事务执行相同的查询两次或两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间更新了数据。
• 幻读（Phantom read）：幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录。

在理想情况下，事务之间是完全隔离的，从而可以防止这些问题发生。但考虑到完全的隔离会导致性能问题，而且并不是所有的应用程序都需要完全的隔离，所以有时应用程序需要在事务隔离上有一定的灵活性。因此，就会有多种隔离级别。

隔离级别	含义
ISOLATION_DEFAULT	使用后端数据库默认的隔离级别
ISOLATION_READ_UNCOMMITTED	允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读，是事务隔离程度最低的隔离级别
ISOLATION_READ_COMMITTED	允许读取并发事务已经提交的数据。可以组织脏读，但是幻读或不可重复读仍有可能发生
ISOLATION_REPEATABLE_READ	对同一个字段的多次读取结果是一致的，除非数据是被本事务所修改，可以组织脏读和不可重复读，但幻读仍有可能发生
ISOLATION_SERIALIZABLE	完全服从ACID的隔离级别，确保阻止脏读、不可重复读以及幻读。这是最慢的事务隔离级别，因为它通常是通过完全锁定事务相关的数据库来实现的

只读
如果事务只对后端的数据库进行只读操作，数据库可以利用事务的只读特性来进行一些特定的优化。通过将事务设置为只读，你就可以给数据库一个机会，让它应用它认为合适的优化措施。

因为只读优化是在事务启动的时候由数据库实施的，只有对那些具备启动一个新事务的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW 以及 PROPAGATION_NESTED
）的方法来说，将事务声明为只读才有意义。

另外，如果采用 Hibernate 作为持久化机制，那么僵事务声明为只读会导致 Hibernate 的 flush 模式被设置为 FLUSH_NEVER。这会告诉 Hibernate 避免和数据库进行不必要的对象同步，并将所有的更新延迟到事务结束。

事务超时
为了使应用程序很好地运行，事务不能运行太长的时间。假设事务的运行时间变得特别长，因为事务可能涉及对后端数据库的锁定，所以长时间的事务会不必要地占用数据库资源。你可以声明一个事务，在特定的秒数后自动回滚，而不是等待其结束。

因为超时时钟会在事务开始时启动，所以，只有对那些具备可能启动一个新事务的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW 以及 PROPAGATION_NESTED）的方法来说，声明事务超时才有意义。

回滚规则
回滚规则定义了哪些异常会导致事务回滚而哪些不会。默认情况下，事务只有在遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行为是一致的）

6.4.2 在 XML 中定义事务

简单样例参考
Spring 提供了一个 tx 配置命名空间，借助它可以极大地简化 Spring 中的声明式事务。使用 tx 命名空间会涉及将其添加到 Spring XML 配置文件中：

<?xml version="1.0" encoding="UTF-8"?>
<!-- aop 命名空间也应该包括在内，因为有一些声明式事务配置元素依赖于部分 Spring 的 AOP 配置元素 -->
<beans xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/aop
        http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
        http://www.springframework.org/schema/tx
        http://www.springframework.org/schema/tx/spring-tx-3.0.xsd" >

这个 tx 命名空间提供了一些新的 XML 配置元素，其中，<tx:advice> 用于声明事务性策略。

<!-- 未显示声明配置事务管理器Bean，默认配置 id 为 transactionManager 的 Bean -->
<tx:advice id="txAdvice">
    <tx:attributes>
        <!-- 声明名称以 save 开头的方法需要事务 -->
        <tx:method name="save*" propagation="REQUIRED"/>
        <!-- 其他方法声明如果存在当前事务，它们将会在事务中运行，但是它们并不要求必须在事务中运行 -->
        <tx:method name="*" propagation="SUPPORTS" read-only="true"/>
    </tx:attributes>
</tx:advice>

对于<tx:advice>来说，事务属性定义在<tx:attributes>元素中，该元素包含了一个或多个的<tx:method>元素。<tx:method>元素为某个（或某些）name 属性（使用通配符）指定的方法定义事务参数。

<tx:method>有多个属性来帮助定义方法的事务策略：

属性	含义
isolation	指定事务的隔离级别
propagation	定义事务的传播规则
read-only	指定事务的只读
回滚规则：rollback-for / no-rollback-for	指定事务对于哪些检查型异常应当回滚而不提交 / 指定事务对于哪些异常应当继续运行而不回滚
timeout	对于长时间运行的事务定义超时时间

当使用<tx:advice>来声明事务时，你还需要一个事务管理器。<tx:advice>假定事务管理器被声明为一个 id 为 transactionManager 的 Bean 。如果需要配置 id 名不同的事务管理器，则需要在 transaction-manager 属性中明确指定事务管理器的 id ：

<tx:advice id="txAdvice" transaction-manager="xxx">
    ...
</tx:advice>

<tx:advice>只是定义了 AOP 通知，用于把事务的边界通知给方法。为了完整定义事务性切面，我们必须定义一个通知器（advisor）。这就涉及 aop 命名空间了。

以下的 XML 定义了一个通知器：

<!-- 使用 txAdvice 通知所有实现 SpitterService 接口的 Bean -->
<aop:config>
    <aop:advisor advice-ref="txAdvice"
        pointcut="execution(* *..SpitterService.*(..))"/>
</aop:config>

6.4.3 定义注解驱动的事务

除了<tx:advice>元素，tx 命名空间还提供了<tx:annotation-driven> 元素。使用<tx:annotation-driven />时，通常只需要一行 XML。

<tx:annotation-driven> 元素告诉 Spring 检查上下文中所有的 Bean 并查找使用 @Transactional 注解的 Bean，而不管这个注解是用在类级别上还是方法级别上。

我们可以通过 transaction-manager 属性来指定特定的事务管理器（不配置默认值为 transactionManager）

对于每一个使用 @Transactional 注解的 Bean，<tx:annotation-driven> 会自动为它添加事务通知。通知的事务属性是通过 @Transactional 注解的参数来定义的。

@Transactional( propagation=Propagation.SUPPORTS, readOnly=true )
public class SpitterServiceImpl implements SpitterService {
    //...
    @Transactional( propagation=Propagation.REQUIRED,readOnly=false )
    public void addSpitter(Spitter spitter){
        //...
    }

}