数据访问事务处理 in Spring+Mybatis3.0

事务---保证了用户的每一次操作都是可靠的，即使出现了异常的访问，也不至于破坏后台数据的完整性;

事务必须符合ISO/IEC所定制的ACID原则

1)       A(atomicity):原子性

在事务执行的过程中,任何的失败就将导致事务的任何修改失效,

2)       C(consistency):一致性

事务回滚时,事务所执行的内容必须恢复到初始状态,即事务执行前的状态

3)       I(isolation):隔离性

事务执行过程中对数据的修改,在提交之前的数据对其他事务不可见

4)       D(durability):持久性

已经提交的数据在事务执行失败时,数据的状态都是正确的.

事务分类:

全局事务(分布式事务):

        由应用服务器来管理(如JTA),同时可以用于多个事务性的资源;

本地事务

本地事务和资源相关,主要通过JDBC来实现

在实际应用中,存在一种容器管理事务,容器事务主要是由javaEE应用服务器提供,容器事务大多给予JTA完成,事实上这是在容器中覆盖了JDBC和JTA事务.

Code:

public  interface TransactionDefinition{

int getIsolationLevel();

int getPropagationBehavior();

int getTimeout();

boolean isReadOnly();

}

a)      事务隔离级别

隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量：

    TransactionDefinition.ISOLATION_DEFAULT(默认值)：表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。

    TransactionDefinition.ISOLATION_READ_UNCOMMITTED：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读和不可重复读，因此很少使用该隔离级别。

    TransactionDefinition.ISOLATION_READ_COMMITTED：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值。

    TransactionDefinition.ISOLATION_REPEATABLE_READ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。即使在多次查询之间有新增的数据满足该查询，这些新增的记录也会被忽略。该级别可以防止脏读和不可重复读。

TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

隔离级别定义了事务与事务之间的隔离程度。

隔离级别与并发性是互为矛盾的：隔离程度越高，数据库的并发性越差；隔离程度越低，数据库的并发性越好。

    ANSI/ISO SQL92标准定义了一些数据库操作的隔离级别：

        未提交读(read uncommitted)

        提交读(read committed)

        重复读(repeatable read)

        序列化(serializable)

通过一些现象，可以反映出隔离级别的效果。这些现象有：

更新丢失(lost update)：当系统允许两个事务同时更新同一数据是，发生更新丢失。

脏读(dirty read)：当一个事务读取另一个事务尚未提交的修改时，产生脏读。

非重复读(nonrepeatable read)：同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。(A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data.)

幻读(phantom read)：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，每次返回不同的结果集，此时发生幻像读。(A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another committed transaction has inserted additional rows that satisfy the condition.)

隔离级别影响部分：

b)       事务传播行为

所谓事务的传播行为是指，如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量：

TransactionDefinition.PROPAGATION_REQUIRED：

如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。

TransactionDefinition.PROPAGATION_REQUIRES_NEW：

创建一个新的事务，如果当前存在事务，则把当前事务挂起。

TransactionDefinition.PROPAGATION_SUPPORTS：

如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。

TransactionDefinition.PROPAGATION_NOT_SUPPORTED：

以非事务方式运行，如果当前存在事务，则把当前事务挂起。

TransactionDefinition.PROPAGATION_NEVER：

以非事务方式运行，如果当前存在事务，则抛出异常。

TransactionDefinition.PROPAGATION_MANDATORY：

如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。

TransactionDefinition.PROPAGATION_NESTED：

如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

                    此处涉及到【嵌套事务】

                      内部事务依赖于外部事务

                              外部事务的提交和回滚直接影响到内部事务（内部事务不是独立的）

c)        事务超时

                    指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。在 TransactionDefinition 中以 int 的值来表示超时时间，其单位是秒。

d)       事务的只读属性（readOnly）

对事务性资源进行只读操作或者是读写操作。所谓事务性资源就是指那些被事务管理的资源，比如数据源、 JMS 资源，以及自定义的事务性资源等等。如果确定只对事务性资源进行只读操作，那么我们可以将事务标志为只读的，以提高事务处理的性能。在 TransactionDefinition 中以 boolean 类型来表示该事务是否只读。

           e)  事务的回滚规则

通常情况下，如果在事务中抛出了未检查异常（继承自 RuntimeException 的异常），则默认将回滚事务。如果没有抛出任何异常，或者抛出了已检查异常，则仍然提交事务。这通常也是大多数开发者希望的处理方式，也是 EJB 中的默认处理方式。但是，我们可以根据需要人为控制事务在抛出某些未检查异常时任然提交事务，或者在抛出某些已检查异常时回滚事务。

事务管理，其实就是“按照给定的事务规则来执行提交或者回滚操作”。“给定的事务规则”就是用TransactionDefinition 表示的，“按照……来执行提交或者回滚操作”便是用 PlatformTransactionManager 来表示，而 TransactionStatus 用于表示一个运行着的事务的状态。

PlatformTransactionManager 用于执行具体的事务操作。

Public interface PlatformTransactionManager{

  TransactionStatus getTransaction(TransactionDefinition definition)

   throws TransactionException;

   void commit(TransactionStatus status)throws TransactionException;

   void rollback(TransactionStatus status)throws TransactionException;

}

           根据底层所使用的不同的持久化 API 或框架，PlatformTransactionManager 的主要实现类大致如下：

    DataSourceTransactionManager：适用于使用JDBC和iBatis进行数据持久化操作的情况。

    HibernateTransactionManager：适用于使用Hibernate进行数据持久化操作的情况。

    JpaTransactionManager：适用于使用JPA进行数据持久化操作的情况。

    另外还有JtaTransactionManager 、JdoTransactionManager、JmsTransactionManager等等。

如果我们使用JTA进行事务管理，我们可以通过 JNDI 和 Spring 的 JtaTransactionManager 来获取一个容器管理的 DataSource。JtaTransactionManager 不需要知道 DataSource 和其他特定的资源，因为它将使用容器提供的全局事务管理。而对于其他事务管理器，比如DataSourceTransactionManager，在定义时需要提供底层的数据源作为其属性，也就是 DataSource。与 HibernateTransactionManager 对应的是 SessionFactory，与 JpaTransactionManager 对应的是 EntityManagerFactory 等等。

PlatformTransactionManager.getTransaction(…) 方法返回一个 TransactionStatus 对象。返回的TransactionStatus 对象可能代表一个新的或已经存在的事务（如果在当前调用堆栈有一个符合条件的事务）。TransactionStatus 接口提供了一个简单的控制事务执行和查询事务状态的方法。

public  interface TransactionStatus{

   boolean isNewTransaction();

   void setRollbackOnly();

   boolean isRollbackOnly();

}

在 Spring 出现以前，编程式事务管理对基于 POJO 的应用来说是唯一选择。用过 Hibernate 的人都知道，需要在代码中显式调用beginTransaction()、commit()、rollback()等事务管理相关的方法，这就是编程式事务管理。通过 Spring 提供的事务管理 API，我们可以在代码中灵活控制事务的执行。在底层，Spring 仍然将事务操作委托给底层的持久化框架来执行。

Spring 的声明式事务管理在底层是建立在 AOP 的基础之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。

声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明（或通过等价的基于标注的方式），便可以将事务规则应用到业务逻辑中。因为事务管理本身就是一个典型的横切逻辑，正是 AOP 的用武之地。

通常情况下，笔者强烈建议在开发中使用声明式事务，不仅因为其简单，更主要是因为这样使得纯业务代码不被污染，极大方便后期的代码维护。

<beans>

<bean id="transactionInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor">

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

<property name="transactionAttributes">

<props>

<prop key="transfer">PROPAGATION_REQUIRED,-XXException,+xxxException</prop>

</props>

</property>

</bean>

<bean id="serviceTarget" class="com.ncs.test.TestService">

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

</bean>

<bean id="service"  class="org.springframework.aop.framework.ProxyFactoryBean">

<property name="target" ref=" serviceTarget "/>

<property name="interceptorNames">

<list>

<idref bean="transactionInterceptor"/>

</list>

</property>

</bean>

</beans>

我们配置了一个 TransactionInterceptor 来定义相关的事务规则，他有两个主要的属性：一个是 transactionManager，用来指定一个事务管理器，并将具体事务相关的操作委托给它；另一个是 Properties 类型的 transactionAttributes 属性，它主要用来定义事务规则，该属性的每一个键值对中，键指定的是方法名，方法名可以使用通配符，而值就表示相应方法的所应用的事务属性。

指定事务属性的取值有较复杂的规则：

格式：

传播行为 [，隔离级别] [，只读属性] [，超时属性] [不影响提交的异常] [，导致回滚的异常]

Ø  传播行为是唯一必须设置的属性，其他都可以忽略，Spring为我们提供了合理的默认值。

Ø  传播行为的取值必须以“PROPAGATION_”开头，具体包括：PROPAGATION_MANDATORY、PROPAGATION_NESTED、PROPAGATION_NEVER、PROPAGATION_NOT_SUPPORTED、PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW、PROPAGATION_SUPPORTS，共七种取值。

Ø  隔离级别的取值必须以“ISOLATION_”开头，具体包括：ISOLATION_DEFAULT、ISOLATION_READ_COMMITTED、ISOLATION_READ_UNCOMMITTED、ISOLATION_REPEATABLE_READ、ISOLATION_SERIALIZABLE，共五种取值。

Ø  如果事务是只读的，那么我们可以指定只读属性，使用“readOnly”指定。否则我们不需要设置该属性。

Ø  超时属性的取值必须以“TIMEOUT_”开头，后面跟一个int类型的值，表示超时时间，单位是秒。

Ø  不影响提交的异常是指，即使事务中抛出了这些类型的异常，事务任然正常提交。必须在每一个异常的名字前面加上“+”。异常的名字可以是类名的一部分。比如“+RuntimeException”、“+tion”等等。

Ø  导致回滚的异常是指，当事务中抛出这些类型的异常时，事务将回滚。必须在每一个异常的名字前面加上“-”。异常的名字可以是类名的全部或者部分，比如“-RuntimeException”、“-tion”等等。

Ø  例子：

<property name="*Service">

PROPAGATION_REQUIRED，ISOLATION_READ_COMMITTED，TIMEOUT_20，+AbcException，+DefException，-HijException

</property>

前面的声明式事务虽然好，但是配置文件太多。我们必须针对每一个目标对象配置一个ProxyFactoryBean；另外，虽然可以通过父子 Bean 的方式来复用 TransactionInterceptor 的配置，但是实际的复用几率也不高；这样，加上目标对象本身，每一个业务类可能需要对应三个 <bean/> 配置，随着业务类的增多，配置文件将会变得越来越庞大，管理配置文件又成了问题。

为了缓解这个问题，Spring 为我们提供了 TransactionProxyFactoryBean，用于将TransactionInterceptor 和 ProxyFactoryBean 的配置合二为一。

<beans>

<bean id="testServiceTarget"  class="org.test.core.Test">

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

</bean>

<bean id="testService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

<property name="target" ref=" testServiceTarget "/>

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

<property name="transactionAttributes">

<props>

<prop key="transfer">PROPAGATION_REQUIRED</prop>

</props>

</property>

</bean>

</beans>

前面两种声明式事务配置方式奠定了 Spring 声明式事务管理的基石。在此基础上，Spring 2.x 引入了 <tx> 命名空间，结合使用 <aop> 命名空间，带给开发人员配置声明式事务的全新体验，配置变得更加简单和灵活。另外，得益于 <aop> 命名空间的切点表达式支持，声明式事务也变得更加强大。

XML:

<beans>

<bean id=" testService " class="com.ncs.test testService">

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

</bean>

<tx:advice id="testAdvice" transaction-manager="transactionManager">

<tx:attributes>

<tx:method name="transfer" propagation="REQUIRED"/>

</tx:attributes>

</tx:advice>

<aop:config>

<aop:pointcut id="testPointcut" expression="execution(* *.transfer(..))"/>

<aop:advisor advice-ref="testAdvice" pointcut-ref="testPointcut"/>

</aop:config>

</beans>

简化：

<beans>

<bean id="testService" class=" com.ncs.test testService ">

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

</bean>

<tx:advice id="testAdvice" transaction-manager="transactionManager">

<aop:config>

<aop:pointcut id="testPointcut" expression="execution(**.transfer(..))"/>

<aop:advisor advice-ref="testAdvice" pointcut-ref="testPointcut"/>

</aop:config>

</beans>

事务配置：

         <bean name="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

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

</bean>

启用注释：

<tx:annotation-driv

在 MyBatis 中有两种事务管理器类型（也就是 type=”[JDBC|MANAGED]”）：

  JDBC – 这个配置直接简单使用了JDBC 的提交和回滚设置。它依赖于从数据源得到的连接来管理事务范围。

  MANAGED – 这个配置几乎没做什么。它从来不提交或回滚一个连接。而它会让容器来管理事务的整个生命周期（比如 Spring 或 JEE应用服务器的上下文）。默认情况下它会关闭连接。然而一些容器并不希望这样，因此如果你需要从连接中停止它，将 closeConnection 属性设置为 false。例如：

<transactionManager type="MANAGED">

<property name="closeConnection" value="false"/>

</transactionManager>

这两种事务管理器都不需要任何属性。然而它们都是类型别名，要替换使用它们，你需要放置将你自己的类的完全限定名或类型别名，它们引用了你对 TransacFactory 接口的实现类。

  public interface TransactionFactory {

void setProperties(Properties props);

Transaction newTransaction(Connection conn, boolean autoCommit);

}

  任何在 XML 中配置的属性在实例化之后将会被传递给 setProperties()方法。你的实现类需要创建一个事务接口的实现，这个接口也很简单：

  public interface Transaction {

Connection getConnection();

void commit() throws SQLException;

void rollback() throws SQLException;

void close() throws SQLException;

}

  使用这两个接口，你可以完全自定义 MyBatis 对事务的处理