2015第24周一Spring事务

1. Spring事务管理简介

（1）Spring为多种不同类型的事务管理机制提供统一编程模型，这些事务管理模型包括JTA、JDBC、Hibernate、JPA和JDO。

（2）Spring支持声明式事务管理（使用XML文档配置（或者Annotation）结合AOP实现的事务管理）。

（3）为代码嵌入式（programmatic）的事务管理提供API接口，与复杂的JTA接口相比要简单的多。

（4）能够与Spring的数据抽象访问完美结合。

2． Spring事务管理的优点

一般认为，JavaEE中有两种类型的事务管理方式，分别是全局（global）和局部（local）事务。它们各自有优缺点。

2.1 全局事务

全局事务主要是指通过JTA管理多个数据库或者消息队列的事务处理。JTA接口使用复杂，并且必须结合JNDI才能使用，因此限制了应用代码潜在的重用性。

此外，EJB的CMT（Container Manager Transaction），使用声明式事务管理，无需使用JNDI的支持，但是需要引入EJB相应的服务。

2.2 局部事务

局部事务是资源（数据库）相关的，例如JDBC的connection。尽管局部事务使用简单，但是其缺点也是很明显的：局部事务不能在多个源（数据库）间统一管理事务，此外事务管理使用嵌入式代码，不利于代码逻辑的清晰展现。

2.3 Spring一致性编程模型

Spring解决了全局和局部事务的缺陷，使用一致性编程模型，一次编码，可以在不同的事务策略和运行环境中迁移。此外，Spring提供两种类型的事务管理方式，分别是代码嵌入式和声明式，更多的人喜欢使用声明式。

笔者注：Spring的事务管理依赖于底层的具体事务管理框架，比如，如果底层的事务管理框架是全局的（例如JTA、或者是CMT），那么Spring的事务管理就是全局的，如果底层的事务管理是局部的（例如：Hibernate、JDBC，JDO等），则Spring的事务管理就是局部的。在很多情况下，即使使用的是EJB的CMT管理多个数据源（数据库），可能仍然会选择使用Spring事务管理应用，因为Spring提供一种声明式的事务管理机制，在对已有代码进行零改动（使用XML+AOP）或者略微改动（使用Annotation+AOP）的情况下，统一管理事务，因此，有利于代码在不同的事务策略和运行环境中迁移。

3. Spring事务抽象

Spring的事务管理通过org.springframework.transaction.PlatformactionManager接口表示：

public interface PlatformTransactionManager {

TransactionStatus getTransaction(TransactionDefinition definition)

throws TransactionException;

void commit(TransactionStatus status) throws TransactionException;

void rollback(TransactionStatus status) throws TransactionException;

}

PlatformTransactionManager是一个服务提供商接口（SPI），针对不同类型的底层事务框架，Spring提供了不同的PlatFormTransactionManager实现版本，在使用过程中选择适当的实现版本管理底层事务框架即可，常见的有：

（1）JDBC org.springframework.jdbc.datasource.DataSourceTransactionManager

（2）JTA  org.springframework.transaction.jta.JtaTransactionManager

（3）Hibernate org.springframework.orm.hibernate3.HibernateTransactionManager

下面分析PlatFormTransactionManager中的方法，getTransaction方法，通过TransactionDefinition传入参数返回TransactionStatus对象。TransactionStatus可能表示一个新的事务，或者表示一个已经存在的事务（如果当前线程的调用栈中已经存在一个事务）。在JavaEE中经常将事务与一个具体的执行线程相关联，因此，在获取事务时，如果当前线程中已经存在事务，即将存在的事务返回，否则创建一个新事务返回。

TransactionDefinition接口规范如下：

（1）Isolation：事务隔离等级（是数据库事务的一个概念，不同数据库支持不同的事务隔离等级）

（2）Propagation：事务传播方式，通过设置可以决定，当一个事务方法准备执行前，线程栈中已经存在一个事务，可选的策略为：使用先前的事务作为即将执行的方法事务，或者，将先前的事务暂停，创建一个全新的事务处理当前方法，处理结束后，在返回先前的事务。

（3）Timeout：如果事务持续的时间超时，则启动底层事务管理的回滚机制，回滚当前事务。

（4）Read-only status：Read-only事务主要应用于代码中仅读取数据，并未对数据修改的情况。在某些情况下，Read-only事务可以优化事务管理，例如底层事务框架使用Hibernate时。

TransactionStatus提供了简单的方式控制事务执行和查询事务状态，如下所示：

public interface TransactionStatus extends SavepointManager {

    boolean isNewTransaction();

    boolean hasSavepoint();

    void setRollbackOnly();

    boolean isRollbackOnly();

    void flush();

    boolean isCompleted();

}

针对不同的底层事务框架，需要选择正确的PlatformTransactionManager实现版本，下面提供Hibernate的配置方法：

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

  <property name="dataSource" ref="dataSource" />

  <property name="mappingResources">

  <list>

    <value>org/springframework/samples/petclinic/hibernate/petclinic.hbm.xml</value>

  </list>

  </property>

  <property name="hibernateProperties">

    <value>

      hibernate.dialect=${hibernate.dialect}

    </value>

  </property>

</bean>

<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">

  <property name="sessionFactory" ref="sessionFactory" />

</bean>

从上述配置文件可以看出，需要在txManager中指定Hibernate Sessionfactory。在Hibernate中通过Sessionfactory中的OpenSession方法创建Session，之后使用Session中的beginTransaction方法开启事务。将sessionFactory注入到HibernateTransactionManager中的属性后，Spring即可通过这个sessionFactory控制Hibernate事务管理。所以，Spring事务管理仍然是依赖于底层的事务管理框架，而Spring只是提供对事务的一种抽象，这种抽象能够在多种事务框架间迁移。当需要新的事务管理框架和策略支持时，无需更改代码，只需更改配置文件即可完成这种事务框架间的迁移。

4. 使用事务同步资源（略）

5.声明式（Declarative）事务管理

声明式事务管理以EJB的CMT十分类似，它们的主要区别在于：

（1）CMT依赖于JTA，只适用于全局事务管理，Spring不单可以适用于JTA，同时也适用于局部事务管理（例如：JDBC，JPA，Hibernate和JDO等）。

（2）Spring声明式事务管理可以应用于任意的类管理，而EJBs只是用于特殊类管理。

（3）Spring的回滚规则与EJB不同。

（4）Spring可以通过AOP规则在回滚过程中插入用户定义行为，也可以同事务管理advice一起定义任意的advice。（advice是AOP的概念）

（5）Spring不支持跨越多个远程调用的事务管理。一般认为Spring的事务最多在一个请求范围内完成，如果需要跨越多个请求过程管理事务，那么应当选择EJB，但是这种情况并不多见。

回滚规则的制定十分重要。当然，可以使用传统的方式，调用TransactionStatus中的setRollback方法，通过代码回滚事务；但是，更常用的是定义回滚规则，当应用程序执行过程中满足了某项回滚规则（定义制定Runtime exception出发事务回滚），当前事务应当自动回滚。通过Spring的声明式事务管理，无需在代码中加入任何与事务相关的内容，即可完成按回滚规则管理事务的方式。Spring与EJB相似，仅对未处理的运行时异常（runtime exception）回滚。

5.1 理解声明式事务实现机制

Spring通过元数据（metadata，包括XML或者annotation）配置声明式事务管理，并使用AOP代理机制最终实现事务管理。过程大致是，开发者通过元数据标明需要事务管理的方法（通过AOP中的cut-point），同时提供事务管理的策略advice（通过TX的advice），并结合实际提供的PlatformTransactionManager。当用户调用了事务管理方法时，系统使用具体的PlatformTransactionManager实现，根据advice提供的策略创建（或者获取）一个事务，之后执行方法内部逻辑，当出现异常时，回滚当前事务，否则执行结束，提交事务，清理当前事务。整个过程是使用AOP代理完成的，AOP代理在方法代码前添加事务启动逻辑，在方法执行后添加事务提交和清理逻辑，并且代理监控方法中可能出现的异常，当有未捕获异常抛出时，代理使用相应的回滚逻辑回滚事务。（有关代理的更进一步说明请参考Spring官方文档AOP章节）。整个过程如下图所示：

5.2 声明式事务管理举例

// the service interface that we want to make transactional

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

}

// an implementation of the above interface

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();

  }

}

下面声明get方法为read-only，而其他方法为默认。

<bean id="fooService" class="x.y.service.DefaultFooService"/>

  <!-- the transactional advice (what 'happens'; see the <aop:advisor/> bean below) -->

  <tx:advice id="txAdvice" transaction-manager="txManager">

  <!-- the transactional semantics... -->

  <tx:attributes>

    <!-- all methods starting with 'get' are read-only -->

    <tx:method name="get*" read-only="true"/>

    <!-- other methods use the default transaction settings (see below) -->

    <tx:method name="*"/>

  </tx:attributes>

  </tx:advice>

  <!-- ensure that the above transactional advice runs for any execution

    of an operation defined by the FooService interface -->

  <aop:config>

  <aop:pointcut id="fooServiceOperation" expression="execution(* x.y.service.FooService.*(..))"/>

  <aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceOperation"/>

  </aop:config>

  <!-- don't forget the DataSource -->

  <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

  <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>

  <property name="url" value="jdbc:oracle:thin:@rj-t42:1521:elvis"/>

  <property name="username" value="scott"/>

  <property name="password" value="tiger"/>

  </bean>

  <!-- similarly, don't forget the PlatformTransactionManager -->

  <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

  <property name="dataSource" ref="dataSource"/>

  </bean>

正如上例所述的那样，通过<tx:advice/>标签设置了“所有以get开始的方法需要使用read-only事务管理策略，而其它方法使用默认的事务管理策略”。transaction-manager属性用于指定具体的PlatformTransactionManager实现，txAdvice需要使用txManager驱动具体的事务管理过程。因此，pointcut标明需要添加事务代理的方法，通过advice配置了事务属性和事务管理者，当需要事务支持的方法被调用时，aop使用advice找到PlatformTransactionManager，而PlatformTransactionManager使用底层的具体事务管理架构，最终实现事务管理功能。

5.3 回滚配置

默认情况下，Spring只会对方法中的未检测运行异常回滚，而被检测的异常不会导致事务回滚。

可以通过如下配置方法甚至配置一个检测的异常回滚：

<tx:advice id="txAdvice" transaction-manager="txManager">

  <tx:attributes>

  <tx:method name="get*" read-only="true" rollback-for="NoProductInStockException"/>

  <tx:method name="*"/>

  </tx:attributes>

</tx:advice>

当然也可以使用下面方法，使一个未检测异常不发生回滚，当这个异常发生时，Spring将提交事务（而不是回滚）：

<tx:advice id="txAdvice">

  <tx:attributes>

  <tx:method name="updateStock" no-rollback-for="InstrumentNotFoundException"/>

  <tx:method name="*"/>

  </tx:attributes>

</tx:advice>

5.4为不同的bean配置不同的advice

<aop:config>

    <aop:pointcut id="defaultServiceOperation"

          expression="execution(* x.y.service.*Service.*(..))"/>

    <aop:pointcut id="noTxServiceOperation"

          expression="execution(* x.y.service.ddl.DefaultDdlManager.*(..))"/>

    <aop:advisor pointcut-ref="defaultServiceOperation" advice-ref="defaultTxAdvice"/>

    <aop:advisor pointcut-ref="noTxServiceOperation" advice-ref="noTxAdvice"/>

  </aop:config>

  <!-- this bean will be transactional (see the 'defaultServiceOperation' pointcut) -->

  <bean id="fooService" class="x.y.service.DefaultFooService"/>

  <!-- this bean will also be transactional, but with totally different transactional settings -->

  <bean id="anotherFooService" class="x.y.service.ddl.DefaultDdlManager"/>

  <tx:advice id="defaultTxAdvice">

    <tx:attributes>

      <tx:method name="get*" read-only="true"/>

      <tx:method name="*"/>

    </tx:attributes>

  </tx:advice>

  <tx:advice id="noTxAdvice">

    <tx:attributes>

      <tx:method name="*" propagation="NEVER"/>

    </tx:attributes>

  </tx:advice>

5.5 <tx:advice/>

（1）propagation 默认是Required

（2）Isolation 默认是Default

（3）Transaction 默认是read/write

（4）timeout 默认-1

（5）rollback-for

（6）no-rollback-for

5.6 使用@Transactional

除了使用XML类型的事务管理，同时Spring也提供了Annotation类型的事务管理。如下所示：

// the service class that we want to make transactional

@Transactional

public class DefaultFooService implements FooService {

Foo getFoo(String fooName);

Foo getFoo(String fooName, String barName);

void insertFoo(Foo foo);

void updateFoo(Foo foo);

}

当然，需要在Spring的配置文档中添加一行，用于说明事务是由哪个txManager管理的。

<!-- from the file 'context.xml' -->

<?xml version="1.0" encoding="UTF-8"?>

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

http://www.springframework.org/schema/tx/spring-tx-3.0.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">

<!-- this is the service object that we want to make transactional -->

<bean id="fooService" class="x.y.service.DefaultFooService"/>

<!-- enable the configuration of transactional behavior based on annotations -->

<tx:annotation-driven transaction-manager="txManager"/>

<!-- a PlatformTransactionManager is still required -->

<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

<!-- (this dependency is defined somewhere else) -->

<property name="dataSource" ref="dataSource"/>

</bean>

<!-- other <bean/> definitions here -->

</beans>

可以使用@Transactional标记一个接口，接口中的方法，一个类的定义或者类中的公共方法。但是仅仅提供@Transactional标记是不够的，@Transactional标记只是一种能够被某种运行时架构使用的配置元数据，因此需要提供能够自动识别@Transactional标记的架构支持。上例中，使用<tx:annotation-driven/>元素开启了标记的事务行为。

注意：当事务管理使用的是代理形式，仅有在公有方法上标记的@Transactional是有效的，所有的私有的、受保护的或者包可见性的方法即使标记了@Transactional也不会有实质性的事务管理行为产生，并且系统不会给出任何错误或者提示信息。如果有必要在非公有方法上标记事务，那么不应当使用代理模式的事务管理，可以考虑使用AspectJ。

注意：Spring提倡将@Transactional标记在类（或者类的方法上），不提倡对接口（或者接口方法进行标记）。在接口或者接口方法上进行@Transactional标记是可行的，但是仅有系统运行在基于接口的代理前提下事务管理才会发生。实际上Java标记不会通过接口继承，这意味着如果你使用基于类的代理（prox-target-calss=”ture”）或者使用weaving-based aspact（mode=”aspectj”）,这样在接口上的标记将不会被代理或者织入架构识别，并且对象不会被事务代理包装，最终无法实现事务管理。

注意：在代理模式中（是Spring事务管理默认使用的），仅有外部方法调用过程才会被代理截获，这意味着自身调用，即一个方法调用了本对象的另外一个方法不会导致一个实质的事务管理代理过程产生，即使是被调用的方法标记了@Transactional。

AspectJ模式与代理模式不同，能够使应用自身调用依然被事务管理包围。AspectJ不使用代理，而是在字节码基础上将事务处理逻辑添加到对象中。（这样代码量明显增加）。

<tx:annotation-driven/>的配置属性描述如下：

（1）transaction-manager，默认transactionManager，事务管理器的名字，仅当事务管理器不是transactionManager时，需要显示指定。

（2）mode，默认proxy，proxy模式仅当外部调用产生时才产生代理。可替代的选项是aspectj，通过更改类的字节码来提供事务功能的织入。aspectJ织入需要提供spring-aspects.jar包支持。

（3）proxy-target-class，默认为false。只适用于proxy方式，用于控制代理创建的方式。当值为true时，基于class类型的代理将被创建，否则，基于标准的JDK接口的代理将被创建。细节查看7.6章。

（4）order，默认为Orderd.LOWEST_PRECEDENCE，定义多个advice执行的次序，默认情况下由系统决定。

Transactional有一些属性可以设置，举例如下：

@Transactional(readOnly = true)

public class DefaultFooService implements FooService {

public Foo getFoo(String fooName) {

// do something

}

// these settings have precedence for this method

@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)

public void updateFoo(Foo foo) {

// do something

}

}

5.6.1 @Transactional设置

（1）value 类型String，可选的属性，用于指定事务管理者的名字（Transaction Manager）。

（2）propagation 类型enum：Propagation。可选的，事务传播行为。

（3）isolation 类型enum：Isolation。可选的，事务隔离级别。

（4）timeout 类型int。事务失效时间。

（5）readonly类型boolean。read/write或者read-only事务设置。

（6）rollbackeFor 类型是Throwable子类的数组（对象）。设置出发rollback异常事件。

（7）rollbackForClassname，类型是Throwable子类的数组（类名）。

（8）noRollbackFor

（9）noRollbackForClassname

5.6.2配置多个Transaction Manager

public class TransactionalService {

@Transactional("order")

public void setSomething(String name) { ... }

@Transactional("account")

public void doSomething() { ... }

}

配置文件如下：

<tx:annotation-driven/>

<bean id="transactionManager1" class="org.springframework.jdbc.DataSourceTransactionManager">

...

<qualifier value="order"/>

</bean>

<bean id="transactionManager2" class="org.springframework.jdbc.DataSourceTransactionManager">

...

<qualifier value="account"/>

</bean>

5.6.3 定义shortcut标记

@Target({ElementType.METHOD, ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Transactional("order")

public @interface OrderTx {

}

@Target({ElementType.METHOD, ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Transactional("account")

public @interface AccountTx {

}

使用方式如下：

public class TransactionalService {

@OrderTx

public void setSomething(String name) { ... }

@AccountTx

public void doSomething() { ... }

}

5.7 事务传播（propagation）

在理解事务传播之前，需要先理解物理（physical）事务和逻辑（logical）事务。物理事务是一个真正的事务，而逻辑事务是某段代码内部的事务处理（例如一个内嵌方法内部）。

5.7.1 Required

PROPAGATION_REQUIRED事务传播方式中，会为每一个方法创建一个逻辑事务。每一个内部逻辑事务可以独立于外部逻辑事务单独设置rollback-only的状态，但是所有的逻辑事务最终都会映射为一个物理事务。所以，内部逻辑事务产生的rollback-only状态将会直接影响到外部逻辑事务的实质提交。

当内部逻辑事务设置rollback-only时，而外部事务仍然没有决定事务是否应该回滚（因为内部设置回滚时，外部并不知道内部已经设置了），这个回滚对外部来说是不可预期的。因此需要在内部抛出一个UnexpectedRollbackException的异常，根据这个预期的行为，外部事务会获得内部事务并没有按照预期的方式执行的通知。如果一个内部的逻辑事务无声的标记了rollback-only，但是外部并有感知到内部的这一变化，那么外部调用者将会继续执行提交。因此，外部调用者需要获得一个UnexpectedRollbackException异常，以便清楚的确定内部事务已经回滚，不要在继续执行提交任务。

5.7.2 RequiredNew

PROPAGATION_REQUIRES_NEW与PROPAGATON_REQUIRED不同，对每一个逻辑事务使用一个完整的物理事务，在这种情况下，底层的物理事务是不同的，因此可以独立的提交和回滚，因此内部的事务回滚状态不会影响到外部事务。

5.7.3 Nested

PROPAGATION_NESTED使用一个物理事务管理多个检查点，事务可以回滚到某个检查点。这种部分回滚策略，允许内部事务回滚自己处理范围，即使内部事务回滚，外部事务依然可以继续执行提交。这种设置只适用于JDBC（JDBC中设置有事务管理的检查点）。

转自:http://blog.sina.com.cn/s/blog_616e189f0100zp16.html