Spring学习笔记（五）——Spring事务服务-JTA

Spring为事务管理提供一流的支持。它同时支持编程式和声明式事务。为实现健壮的企业级应用，事务能担当重要的作用。无论是使用编程式事务还是声明式事务，在开发Spring应用时，开发者都不需要对具体的事务管理实现进行交互。
事务管理抽象是Spring提供的最重要的一种抽象。秉承Spring的设计原则，对于事务管理而言，Spring的事务管理具有如下几方面的优势：
1）对于采用手工控制事务，即程序控制事务的编程方式，Spring提供的事物抽象易于使用。
2）无论底层的事务API是什么，Spring都能够提供一致的编程模型。比如，对于提供分布式事务支持的JTA、JDBC、Hibernate等而言，基于Spring的应用代码等都是一致，而没有专属于某事物API的实现。其中，特定的事务API都可以通过Spring配置文件屏蔽掉。
3）Spring支持声明式事务管理。这主要依赖于Spring AOP提供的功能。因此，Spring AOP在Spring事务抽象服务中起了重要的作用。
4）能够同Spring的DAO抽象进行集成。
5）在不同事务服务间切换，只会涉及到Spring配置文件的修改，而不会涉及到代码的修改。

1.事务管理背景
对于事务管理而言，存在两种事务类型：局部（本地，local）事务和全局（global）事务。
对于本地事务而言，只涉及到单个事务性（可恢复）资源，通常都是JDBC级的事务。对于全局事务而言，通常都涉及到两个以上事务性资源，比如两个不同的数据库、数据库和JMS服务器。如果应用只涉及到单个事务性资源，则无需借助于J2EE应用服务器提供的JTA能力，而只需借助于本地事务即可解决事务管理服务方面的问题。如果应用涉及到两个以上的事务性资源，则需要J2EE应用服务器的JTA能力。
从性能上考虑，全局事务是“致命”的。能够不用全局事务，则尽量不用。但对于企业级应用而言，经常不可避免地碰到这种场景。为在应用代码中使用JTA功能，必须通过JNDI获得JTA的引用，继而应用代码需要处理大量的受查异常。对于Web容器而言，通常都不提供JTA的实现，即不支持全局事务，除非外挂JTA事务管理器实现，比如Open Source JOTM。对于J2EE应用服务器而言，比如JBoss、WebLogic、WebSphere、Oracle Application Server、Sun Java System Application Server等，都提供了对JTA的支持。当然不同的应用服务器对JTA的支持程度也不尽相同。
从易用性角度考虑，本地事务更容易使用。但是，它不能保证同事处理多个事务性资源的正确性。通常，事务都具有ACID的特性。
1）A原子性。事务必须成功提交，或者回滚；
2）C一致性；
3）I隔离性；
4）D持久性
ACID，是所有事务管理过程中必须保证的特性。
EJB提供的容器事务管理（Container Managed Transaction，CMT），可以通过在ejb-jar.xml文件中进行事务声明，而不需要应用代码的介入。但是CMT要求EJB容器支持，且只对EJB容器有效。在实际应用中，如何对POJO生效类似的CMT功能呢？
Spring可以解决这个问题。Spring承诺：在任何场景中，使用一致的编程模型，而不会影响对事务的使用；或者说，在使用事务的地方，不会影响编程的模式。尽管Spring同时提供了对声明式和编程式的事务管理支持，不过推荐使用声明式的事务管理。在大部分场合，编程式的事务管理更具灵活性。不过在引入Spring AOP后，情况未必是这样。

2.Spring对事务管理提供的支持
Spring同时支持如下两种事务编程模型：声明式和编程式
对于声明式事务而言，Spring支持各种事务管理器，而不像EJB。EJB仅仅支持JTA(Java Transaction API)。注意，JTA是EJB（对于容器管理事务而言）提供事务支持的唯一事务实现。借助于Spring AOP模块，能够实现Spring提供的声明式事务管理。在J2EE平台中，事务常常作为企业级服务看待，因此它是系统级的。企业应用在完成业务逻辑操作时，需要借助于事务服务，因此将Spring提供的事务抽象作为AOP中的Aspect看待时很合理的事情，即在Spring中提供了事务方面（Aspect），这同JBoss AOP提供的事务方面类似。在Spring事务抽象服务中，提供了TransactionProxyFactoryBean类，供实现声明式事务使用。
对编程式事务而言，Spring也支持各种事务管理器。而且，它比声明式事务更灵活。如果在Spring应用中，仅仅使用到单个的事务性资源，则开发者可以不使用JTA实现。比如，可以直接使用JDBC（DataSourceTransactionManager）、Hibernate、JDO、OJB、JMS、JTA。为支持全局事务，即存在两个以上的事务性资源，则必须借助于第三方JTA实现，比如Open Source JOTM。
需要注意的是，Spring提供的事务管理器仅仅是对现有的事务实现API（比如，Hibernate、JDBC、JTA）进行封装，其本身并没有提供具体的事务管理实现。
在Spring提供的所有事务管理器中，PlatformTransactionManager是最基本的接口。
Spring提供了若干实现，供Spring Ioc实现控制反转使用。对于Hibernate而言，需要借助于HibernateTransactionManager事务管理器。开发者需为它提供seeionFactory取值。
实际上，HibernateTransactionManager将会事务处理的具体工作委派给Hibernate中的net.sf.hibernate.Transaction对象。其实，在Spring提供的所有事务管理器中，都是对底层事务对象的封装。它自身并没有实现底层事务的管理。符合Spring的设计原则：“不重复开发轮子”。因此，对HibernateTransactionManager的commit和rollback操作将委派给Transaction对象。
   

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

其中，HibernateTransactionManager就是实现了PlatformTransactionManager接口，而且是通过Spring Ioc容器加载的。
Spring提供的实现了PlatformTransactionManager接口的主要事务管理器有：
JDBC事务：借助于DataSourceTransactionManager实现
JTA事务：借助于JtaTransactionManager、WebLogicJtaTransactionManager实现。
Hibernate事务：借助于HibernateTransactionManager实现；
JDO事务：借助于JdoTransactionManager实现；
……

对于JDBC事务而言，需要配置DataSourceTransactionManager。配置示例如下。
   

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

    <bean id="dataSource" 
                class="org.springframework.jndi.JndiObjectFactoryBean">
                <property name="jndiName">
                        <value>java:/MySqlDS</value>
                </property>
        </bean>

   
开发者需要为它准备dataSource取值。至于dataSource的具体来源（是基于JNDI，还是其他机制），DataSourceTransactionManager可以不用关注。这或许是Ioc的好处，而且还可以在产品部署场合动态切换。DataSourceTransactionManager将事务的commit和rollback操作委派给java.sql.Connection。

2.1）声明式事务
在J2EE中，EJB因为可以使用声明式事务而著称。现在Spring也能支持声明式事务，不仅如此，借助于Acegi，Spring还能实现声明式安全性。注：这里的声明式事务针对的是POJO对象。
借助于Spring AOP，Spring提供了TransactionProxyFactoryBean。它是为简化声明式事务处理而引入的代理工厂JavaBean。当然，也可以使用ProxyFactoryBean和TransactionInterceptor的组合。在TransactionProxyFactoryBean内部使用了事务拦截器，即TransactionInterceptor。
（2.1.1）TransactionDefinition
Java对象本身由属性和方法构成。对于事务而言，它也存在若干事务属性。通常，事务会涉及到事务移植、隔离级别、是否只读、事务有效实现等。这些属性都是通过如下接口定义的：TransactionDefinition。它位于org.springframework.transaction包中。
在CMT中，开发者可以对事务移植性（propagation）进行配置。在RDBMS中，可以配置数据库的隔离度（isolation）。
对于事务移植而言，TransactionDefinition定义了7中移植策略。
a）int PROPAGATION_REQUIRED = 0。当前方法必须运行于事务中，这同EJB中声明式事务语义相同。即，如果调用其客户处于事务中，则该方法直接使用该事务；否则，启动新事务。
b）int PROPAGATION_SUPPORTS = 1。当前方法可以在事务中，也可以不在事务中。调用其客户在事务中，则当前方法处于事务中。否则，不处于事务中。
c）int PROPAGATION_MANDATORY = 2。当前方法必须运行于事务中。若调用其客户不在事务中，则抛出异常。
d）int PROPAGATION_REQUIRES_NEW = 3。必须运行于新事务中。无论客户如何，都将启动新事务。
e）int PROPAGATION_NOT_SUPPORTED = 4。当前方法不能运行于事务中。如果调用其客户处于事务中，则在执行到它时，客户所处的事务必须挂起。如果调用其客户不处于事务中，则一切照旧。
f）int PROPAGATION_NEVER = 5。调用当前方法的客户不能处于事务中，否则抛出异常。
g）int PROPAGATION_NESTED = 6。它表明当前方法支持嵌入式事务，即允许事务嵌套。标准的J2EE平台不要求支持嵌套事务。这是对EJB声明式事务的扩展。通常，低端的JTA实现都不支持这种事务移植性。

对于隔离级别，Spring TransactionDefinition定义了5中事务策略。
a）int ISOLATION_DEFAULT = -1。它表明直接使用底层持久化源使用的隔离级别定义。
b）int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED。同Connection定义的TRANSACTION_READ_UNCOMMITTED定义。
c）int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED。同Connection定义的TRANSACTION_READ_COMMITTED定义。
d）int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ。
e）int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE。

对于只读属性而言，Spring TransactionDefinition仅对当前方法新创建的事务有效。通过“readonly”标识。在一些场合设置readonly很有效，比如在使用Hibernate时，如果只是从RDBMS读取数据，则能提高事务效率（避免不必要的flush操作）。
对于事务有效时限而言，Spring TransactionDefinition仅对当前方法新创建的事务有效。通过设置以“timeout_”开头的字符串能够生效有效时限属性。比如“timeout_60”表明事务的有效时限是60秒。默认时，它会使用底层事务系统的超时设置。即：int TIMEOUT_DEFAULT = -1。
上述就是Spring TransactionDefinition的定义，这也是Spring所支持的事务属性设置。
如下是一段applicationContext.xml中的实例：
      

<bean id="example11Service" 
                class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
                <property name="transactionManager">
                        <ref local="transactionManager"/>
                </property>
                <property name="target">
                        <ref local="example11ServiceTarget"/>
                </property>
                <property name="transactionAttributes">
                        <props>
                                <prop key="get*">
                                        PROPAGATION_REQUIRED,readOnly
                                </prop>
                                <prop key="set*">
                                        PROPAGATION_REQUIRED
                                </prop>
                        </props>  
                </property>
        </bean>

注意属性transactionAttributes中的配置，其中对事务的移植性进行了约束。其中，通过transactionManager属性指定事务管理器；通过target属性指定TransactionProxyFactoryBean代理的目标业务对象；通过transactionAttributes属性指定事务策略。在Spring框架中，特意提供了org.springframework.transaction.interceptor.TransactionAttributeEditor，供实现事务策略的手工编辑使用。借助于该属性编辑器，使自定义事务策略的过程更友好。上述配置内容的具体解释如下：
a）对于“get*”：这表明以get开头的业务方法（前提是，位于example11ServiceTarget中定义的JavaBean）必须处于事务中，这是通过PROPAGATION_REQUIRED限定的。如果调用客户不在事务上下文中，或者没有提供事务支持，则会创建新的事务。其中，readonly表明这是只读事务，这对于Hibernate而言特别有意义。
b）对于“set*”：这表明以set开头的业务方法（前提是，位于example11ServiceTarget中定义的JavaBean）必须处于事务中，这是通过PROPAGATION_REQUIRED限定的。如果调用客户不在事务上下文中，或者没有提供事务支持，则会创建新的事务。
c）其中设置的事务属性顺序并不重要，因为TransactionAttributeEditor会自动处理它们。比如PROPAGATION_REQUIRED,readOnly和readOnly,PROPAGATION_REQUIRED含义相同。

对于Spring提供的声明式事务支持，开发者能获得如下几方面的益处：
1）借助于Spring AOP提供了类似EJB CMT（容器事务管理）的功能。而且，能够对POJO进行事务性声明。
2）Spring提供的声明式事务能够适用于任何操作环境。比如，JDBC,Hibernate，JDO等，如果有新的事务性资源的加入，对于Spring应用而言，只需要修改下配置文件即可。
3）Spring还提供了声明式的回滚规则，比如，可以声明：如果某异常一旦抛出，事务必须回滚。比如，在事务属性中设置“-UserException”，则表明在事务处理过程中一旦出现UserException，则回滚当前事务。如设置“+UserException”，则表明在事务处理过程中一旦出现UserException，则提交当前事务。加号表示提交，减号表示回滚。这是很诱人的技术。

另外，Spring还提供了通过元数据（比如借助于Jakarta Commons Attributes）、指定方法名（org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource）、自动代理等方式定义事务策略。

2.2）编程式事务
编程式事务比声明式事务更具灵活性。由于Spring AOP实现的拦截器只能拦截方法级的调用，因此如果需要事务支持，则整个方法处于事务中。如果存在遗留代码需要借助于Spring管理，则此时Spring可能不能够胜任。但无论如何，如果我们架构并设计新的企业应用系统，可以考虑到Spring的这种特性，更何况这是开发者大部分场合需要考虑的情况。
Spring为编程式事务提供了两种策略：
a）直接使用TransactionTemplate：这同JndiTemplate、JdbcTemplate、HibernateTemplate类似。由于TransactionTemplate是线程安全的，可以放心使用。
b）直接使用PlatformTransactionManager实现。开发者可以推导，TransactionTemplate一定需要PlatformTransactionManager实现，否则无法完成事务管理操作。因此，直接借助于PlatformTransactionManager实现一定能完成事务管理操作。当然，直接借助于PlatformTransactionManager实现事务管理，会比使用事务模版完成更多的设置和准备工作。
Spring team推荐：通常都最好使用TransactionTemplate
2.2.1）使用TransactionTemplate
Spring框架提供的、类似TransactionTemplate的模版有许多。它们是采用回调机制实现方法调用的。在方法调用期间，TransactionTemplate会将要求的资源准备好（调用开始）和释放掉（调用结束），这是模版的威力。在Spring中，所有模版都是线程安全的。
在使用TransactionTemplate之前，需要在Spring配置文件中进行配置。示例如下：
       

<bean id="transactionTemplate" 
                class="org.springframework.transaction.support.TransactionTemplate">
                <property name="transactionManager">
                        <ref local="transactionManager"></ref>
                </property>
        </bean>

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

transactionManager是TransactionTemplate的属性，因此事务模版需借助Spring提供的事务管理器实现处理事务管理。事务模版可以使用Hibernate、JTA、JDBC、JDO等事务管理器。
也可以基于TransactionTemplate的构建器来注入对事务管理器的依赖。接下来，开发者便能在java代码中直接使用TransactionTemplate了。依据Spring模版设计原则，Spring为TransactionTemplate准备了两个回调接口：TransactionCallback和TransactionCallbackWithoutResult。
a）org.springframework.transaction.support.TransactionCallback：用于事务的回调接口。通常，它都是伴随着TransactionTemplate并以匿名方式使用的。它仅含有单个方法，即doInTransaction。如果事务操作存在返回值，则使用TransactionCallback。如果不存在返回值，则使用TransactionCallbackWithoutResult接口。
b）org.springframework.transaction.support.TransactionCallbackWithoutResult：继承于TransactionCallback。TransactionCallbackWithoutResult供事务操作不存在返回值时使用。
对于存在返回值的业务方法而言，示例如下：

Object result = tt.execute(new TransactionCallback(){
   public Object doInTransaction(TransactionStatus status){
       try{
          updateOperation1();
          updateOperation2();
          return updateOperation3();
       }catch(RuntimeException ex){
          status.setRollbackOnly();
       }
       return null;
   }
});

其中，开发者需要实现Object doInTransaction(TransactionStatus status)方法。现在updateOperation1()、updateOperation2()、updateOperation3()都处于同一事务中，因此他们构成了ACID的特性。若出现异常，则事务回滚（借助于status的setRollbackOnly实现）。
对于不存在返回值的业务方法而言。示例如下：

Object result = tt.execute(new TransactionCallbackWithoutResult(){
   public void doInTransactionWithoutResult(TransactionStatus status){
          updateOperation1();
          updateOperation2();
          updateOperation3();
  }
});

如果应用需要回滚，则需要调用TransactionStatus对象的setRollbackOnly方法。对于有EJB组件开发经验的人而言，能够看出这与CMT极其相似。
2.2.2）使用PlatformTransactionManager实现
借助于Spring IoC容器提供的控制反转，能够直接在应用代码中直接获得对<bean>元素中定义的PlatformTransactionManager实现。示例如下：

transactionManager = ...;
DefaultTransactionDefinition dtd = new DefaultTransactionDefinition();
dtd.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus status = transactionManager.getTransaction(dtd);
try{
   updateOperation1();
   updateOperation2();
   updateOperation3();
}catch(ApplicationContext ex){
   transactionManager.rollback(status);
   throw ex;
}

注，上面的实现方式也是在模拟TransactionTemplate的行为，因此，在编程式事务中，最好直接使用TransactionTemplate。