spring-事务管理[spring in action3.6笔记]

事务管理——原子性、一致性、隔离性、持久性

理解spring对事务管理的支持

Spring提供对编码式和声明式事务管理的支持。编码式事务允许用户在代码中精确定义事务的边界，而声明式事务（基于AOP，面向切面的特性）有助于用户将操作与事务规则进行解耦。

Spring 通过回调机制将实际的事务实现从事务性的代码中抽象出来。实际上，spring对事务的支持甚至不需要JTA的实现。若应用程序只使用一种持久化资源，spring可以使用持久化机制所提供的事务性支持，包括JDBC,Hibernate以及Java持久化API.。但是如果应用程序的事务跨多个资源，那么spring会使用第三方的JTA实现来支持分布式事务。

JDBC事务

<bean  id=”transactionManager”  class=”org.springframework.jdbc.datasource.DataSourceTransactionManager”>

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

</bean>

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

Hibernate 事务

<bean  id=”transactionManager”  class=”org.springframework.orm.hibernate3.HibernateTransactionManager”>

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

</bean>

HibernateTransactionManager将事务管理委托给org.hibernate.Transaction对象，后者从Hibernate Session中获取到。当事务成功时，HibernateTransactionManager会调用Transaction的commit()方法。反之，调用rollback()方法。

Java持久化API事务（JPA -Java Persistence API）

<bean id=”transactionManager” class=”org.springframework.orm.jpa.JpaTransactionManager”>

   <property name=”entityManagerFactory” ref=”entityManagerFactory” />

</bean>

JpaTransactionManager需要装配一个JPA实体管理工厂(javax.persistence.EntityManagerFactory接口的任意实现)。JpaTransactionManager将与由工厂所产生的JPA EntityManager合作来构建事务。

除了将事务应用于JPA操作，JpaTransactionManager还支持将事务应用于简单的JDBC操作之中，这些JDBC操作所使用的DataSource与entityManagerFactory所使用的DataSource必须是相同的。为了做到这一点，JpaTransactionManager必须装配一个JpaDialect的实现。

若已经配置了EclipseLinkJpaDialect

<bean id=”jpaDialect” class=”org.springframework.ora.jpa.vendor.EclipseLinkJpaDialect” />

则将jpaDialect装配到JpaTransactionManager中，即

<bean id=”transactionManager”class=org.springframework.orm.jpa.JpaTransactionManager”>

    <property name=”entityManagerFactory”  ref=”entityManagerFactory” />

    <property name=”jpaDialect”  ref=”jpaDialect” />

</bean>

但是jpaDialect的实现必须同时支持JPA/JDBC访问，而DefaultJpaDialect不支持。

JTA  (java Transaction API)

如果事务需要跨多个事务资源，如多个数据库，则需要使用JtaTransactionManager。

<bean  id=”transactionManager”  class=”org.springframework.transaction.jta.JtaTransactionManager”>

    <property name=”transactionManagerName” value=”java:/TransactionManager” />

</bean>

JtaTransactionManager将事务委托给一个JTA的实现。JTA规定了应用程序与一个或多个数据源之间协调事务的标准API。transactionManager属性指明了要在JNDI上查找JTA事务管理器。JtaTransactionManager将事务委托给javax.transaction.UserTransaction和javax.transaction.TransactionManager对象。通过UserTransaction.commint()方法来提交事务。反之，调用rollback()。

Spring中的编码事务。

Public void saveSpittle(Spittle spittle){

  spitterDao.saveSpittle(spittle);

}

当spittle保存的时候，底层的持久化机制会做很多的事情。

使用spring的TransactionTemplate添加事务性边界(回调机制),

Public void saveSpittle(final Spittle spittle){

  txTemplate.execute(new TransactionCallback<void>(){

    Public void doInTransaction(TransactionStatus txStatus){

      Try{

        spitterDao.saveSpittle(spittle);

      } catch(RuntimeException e){

        txStatus.setRollbackOnly();

        throw e;

      }

      return null;

    });

}

使用TransactionTemplate需要实现TransactionCallback接口。因为TransactionCallback接口只有一个要实现的方法，通常很简单的将其实现为匿名内部类，而对于事务性代码，将其放在doInTransaction()方法中。调用TransactionTemplate实例的excute()方法时，将会执行TransactionCallback实例中的代码。若发生异常，则调用TransactionStatus对象的setRollbackOnly回滚事务，反之提交事务。

这里需要在SpitterServiceImpl中注入TransactionTemplate，即

<bean id=”spitterService” class=”#######”

   <property  name=”transactionTemplate”

      <bean  class=”org.springframework.transaction.support.TransactionTemplate”>

          <property name=”transactionManager” ref=”transactionManager” />

      </bean>

   </property>

</bean>

这里TransactionTemplate注入了一个transactionManager。在背后，TransactionTemplate使用了PlatformTransactionManager实现来处理特定平台的事务管理细节。

Spring声明式事务

Spring对声明式事务的支持是通过spring AOP框架实现的，因为事务实在应用程序主要功能之上的系统级服务，因此可以将spring事务理解成将方法“包装”上事务边界的切面。

Spring提供3种方式来声明事务边界。

即1.使用spring AOP和TtansactionProxyFactoryBean的代理Bean来实现声明式事务；而更好的方式是2.使用Spring的tx命名空间和3.@Transactional注解。

在spring中，声明式事务是通过事务属性来定义的，事务属性描述了事务策略如何应用到方法上，包含5个方面，（1.传播行为，2.隔离级别，3.回滚规则，4.是否只读，5.事务超时）

传播行为回答了这样一个问题，即新的事务应该被启动还是被挂起，或者方法是否要在事务环境中运行

1.PROPAGATION_MANDATORY：

表示该方法必须在事务中运行。若当前事务不存在，则会抛出一个异常。

2.PROPAGATION_NESTED：

表示如果当前已经存在一个事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在，那么其行为

与PROPAGATION_REQUIRED一样。

3.PROPAGATION_NEVER：

表示当前方法不应该运行在事务上下文中。如果当前正有一个事务在运行，则会抛出异常。

4.PROPAGATION_NOT_SUPPORTED：

表示该方法不应该运行在事务中。如果存在当前事务，在该方法运行期间，当前事务将被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManager。

5.PROPAGATION_REQUIRED：

表示当前方法必须运行在事务中。如果当前事务存在，方法将会在该事务中运行。否则，会启动一个新的事务。

6.PROPAGATION_REQUIRED_NEW：

表示当前方法必须运行在它自己的事务中。一个新的事务将被启动。如果存在当前事务，在该方法运行期间，当前事务被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManager。

7.PROPAGATION_SUPPORTS：

表示当前方法不需要事务上下文，但是如果存在当前事务的话，那么该方法会在这个事务中运行。

隔离级别定义了一个事务可能受其他并发事务影响的程度。

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

1.脏读：一个事务读取了另一个事务改写但尚未提交的数据。若改写在稍后被回滚了，那么获取的数据就是无效的。

2.不可重复读：一个事务执行相同的查询两次或以上，但是每次得到的数据不同。通常因为另一个并发事务在两次查询期间更新了数据。

3.。幻读：一个事务读取了几行数据，接着另一个事务插入了一些数据。在随后的查询中，第一个事务发现多了一些原本不存在的记录。

在理想情况下，事务之间是完全隔离的，从而可以防止这些问题发生。但是完全的隔离会导致性能问题，因为它通常会涉及锁定数据库中的记录，甚至整张表。侵占性的锁定会阻碍并发性，要求事务互相等待以完成各自的工作。

1.ISOLATION_DEFAULT：

使用后端数据库默认的隔离级别

2.ISOLATION_READ_UNCOMMITTED：

允许读取尚未提交的数据变更。可能导致脏读、幻读、不可重复读。

3.ISOLATION_READ_COMMITTED：

允许读取并发事务已经提交的数据。仅可以阻止脏读。

4.ISOLATION_REPEATABLE_READ：

对同一字段的多次读取结果是一致的，除非是被本事务自己所修改。仅可以阻止脏读和不可重复读。

5.ISOLATION_SERIALIZABLE：

完全服从ACID隔离级别，确保阻止脏读，不可重复读以及幻读。即最慢的事务隔离级别，其通常是通过锁定事务相关的数据库表来实现的。

只读