Spring 事务机制详解

时间 2019-11-16

原文原文链接

Spring事务机制主要包括 声明式事务和编程式事务，此处侧重讲解声明式事务，编程式事务在实际开发中得不到普遍使用，仅供学习参考。java

Spring声明式事务让咱们从复杂的事务处理中获得解脱。使得咱们 再也无须要去处理得到链接、关闭链接、事务提交和回滚等这些操做。再也无须要咱们在与事务相关的方法中处理大量的try…catch…finally代码。咱们在使用Spring声明式事务时，有一个很是重要的概念就是事务属性。事务属性一般由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。咱们在进行事务划分时，须要进行事务定义，也就是配置事务的属性。spring

下面分别详细讲解，事务的四种属性，仅供诸位学习参考：sql

Spring在TransactionDefinition接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是Spring事务管理的核心接口。数据库

public interface TransactionDefinition {
  int getPropagationBehavior(); //返回事务的传播行为。
  int getIsolationLevel(); //返回事务的隔离级别，事务管理器根据它来控制另一个事务能够看到本事务内的哪些数据。
  int getTimeout(); //返回事务必须在多少秒内完成。
  boolean isReadOnly(); //事务是否只读，事务管理器可以根据这个返回值进行优化，确保事务是只读的。
}
复制代码

TransactionDefinition接口中定义五个隔离级别：

ISOLATION_DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应；编程

ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别，它充许别外一个事务能够看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。学习

ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另一个事务读取。另一个事务不能读取该事务未提交的数据。这种事务隔离级别能够避免脏读出现，可是可能会出现不可重复读和幻像读。优化

ISOLATION_REPEATABLE_READ 这种事务隔离级别能够防止脏读，不可重复读。可是可能出现幻像读。它除了保证一个事务不能读取另外一个事务未提交的数据外，还保证了避免下面的状况产生(不可重复读)。spa

ISOLATION_SERIALIZABLE 这是花费最高代价可是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。code

在TransactionDefinition接口中定义了七个事务传播行为：

（1）PROPAGATION_REQUIRED 若是存在一个事务，则支持当前事务。若是没有事务则开启一个新的事务。orm

// 事务属性 PROPAGATION_REQUIRED
methodA {
   ……
   methodB();
   …… 
}
// 事务属性 PROPAGATION_REQUIRED
methodB {
   ……
}
复制代码

使用Spring声明式事务，spring使用AOP来支持声明式事务，会根据事务属性，自动在方法调用以前决定是否开启一个事务，并在方法执行以后决定事务提交或回滚事务。

单独调用methodB方法：

main {
   metodB();
}
至关于
Main {
   Connection con=null;
   try{
     con = getConnection();
     con.setAutoCommit(false);
     //方法调用
     methodB();
     //提交事务
     con.commit();
   } Catch(RuntimeException ex) {
     //回滚事务
     con.rollback();
   } finally {
     //释放资源
     closeCon();
   }
}
复制代码

Spring保证在methodB方法中全部的调用都得到到一个相同的链接。在调用methodB时，没有一个存在的事务，因此得到一个新的链接，开启了一个新的事务。

单独调用MethodA时，在MethodA内又会调用MethodB。执行效果至关于：

Main {
   Connection con = null;
   try {
     con = getConnection();
     methodA();
     con.commit();
   } catch(RuntimeException ex) {
     con.rollback();
   } finally {
     closeCon();
   }
}
复制代码

调用MethodA时，环境中没有事务，因此开启一个新的事务.当在MethodA中调用MethodB时，环境中已经有了一个事务，因此methodB就加入当前事务。

（2）PROPAGATION_SUPPORTS 若是存在一个事务，支持当前事务。若是没有事务，则非事务的执行。可是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少量不一样。

// 事务属性 PROPAGATION_REQUIRED
methodA() { 
   methodB();
}
// 事务属性 PROPAGATION_SUPPORTS
methodB() {
   ……
}
复制代码

单纯的调用methodB时，methodB方法是非事务的执行的。当调用methdA时,methodB则加入了methodA的事务中执行。

（3）PROPAGATION_MANDATORY 若是已经存在一个事务，支持当前事务。若是没有一个活动的事务，则抛出异常。

// 事务属性 PROPAGATION_REQUIRED
methodA() {
   methodB();
}
//事务属性 PROPAGATION_MANDATORY 
methodB() { 
   ……
}
复制代码

当单独调用methodB时，由于当前没有一个活动的事务，则会抛出异常throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found"); 当调用methodA时，methodB则加入到methodA的事务中执行。

（4）PROPAGATION_REQUIRES_NEW 老是开启一个新的事务。若是一个事务已经存在，则将这个存在的事务挂起。

//事务属性 PROPAGATION_REQUIRED
methodA() { 
   doSomeThingA();
   methodB();
   doSomeThingB();
}
//事务属性 PROPAGATION_REQUIRES_NEW
methodB() {
   ……
}
复制代码

main() {
   methodA();
}
复制代码

至关于：

main() {
   TransactionManager tm = null;
   try { 
     // 得到一个JTA事务管理器 
     tm = getTransactionManager();
     tm.begin(); 
     // 开启一个新的事务
     Transaction ts1 = tm.getTransaction();
     doSomeThing(); 
     tm.suspend(); // 挂起当前事务 
     try {
       tm.begin();// 从新开启第二个事务 
       Transaction ts2 = tm.getTransaction();
       methodB();
       ts2.commit();// 提交第二个事务
     } catch(RunTimeException ex) {
        ts2.rollback(); // 回滚第二个事务
     } finally { 
        // 释放资源
     }
     // methodB执行完后，复恢第一个事务
     tm.resume(ts1);
     doSomeThingB(); 
     ts1.commit();// 提交第一个事务
   } catch(RunTimeException ex) {
     ts1.rollback();// 回滚第一个事务
   } finally {
     //释放资源
   }
}
复制代码

在这里，我把 ts1称为外层事务，ts2称为内层事务。从上面的代码能够看出，ts2与ts1是两个独立的事务，互不相干。Ts2是否成功并不依赖于ts1。若是methodA方法在调用methodB方法后的doSomeThingB方法失败了，而methodB方法所作的结果依然被提交。而除了methodB以外的其它代码致使的结果却被回滚了。使用PROPAGATION_REQUIRES_NEW,须要使用JtaTransactionManager做为事务管理器。

（5）PROPAGATION_NOT_SUPPORTED 老是非事务地执行，并挂起任何存在的事务。使用PROPAGATION_NOT_SUPPORTED,也须要使用JtaTransactionManager做为事务管理器。

（6）PROPAGATION_NEVER 老是非事务地执行，若是存在一个活动事务，则抛出异常；

（7）PROPAGATION_NESTED若是一个活动的事务存在，则运行在一个嵌套的事务中. 若是没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行。这是一个嵌套事务,使用JDBC 3.0驱动时,仅仅支持DataSourceTransactionManager做为事务管理器。须要JDBC 驱动的java.sql.Savepoint类。有一些JTA的事务管理器实现可能也提供了一样的功能。使用PROPAGATION_NESTED，还须要把PlatformTransactionManager的nestedTransactionAllowed属性设为true;而nestedTransactionAllowed属性值默认为false;

// 事务属性 PROPAGATION_REQUIRED
methodA() {
   doSomeThingA();
   methodB();
   doSomeThingB();
}
//事务属性 PROPAGATION_NESTED
methodB() {
   ……
}
复制代码

若是单独调用methodB方法，则按REQUIRED属性执行。若是调用methodA方法，至关于下面的效果：

main() {
    Connection con = null;
    Savepoint savepoint = null;
    try{
      con = getConnection();
      con.setAutoCommit(false);
      doSomeThingA();
      savepoint = con2.setSavepoint();
      try{
        methodB();
      } catch(RuntimeException ex) {
        con.rollback(savepoint);
      } finally {
        //释放资源 
      }
      doSomeThingB();
      con.commit();
    } catch(RuntimeException ex) {
      con.rollback();
    } finally {
      //释放资源
     }
}
复制代码

当methodB方法调用以前，调用setSavepoint方法，保存当前的状态到savepoint。若是methodB方法调用失败，则恢复到以前保存的状态。可是须要注意的是，这时的事务并无进行提交，若是后续的代码(doSomeThingB()方法)调用失败，则回滚包括methodB方法的全部操做。

嵌套事务一个很是重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所作的动做。而内层事务操做失败并不会引发外层事务的回滚。

PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别:

它们很是相似,都像一个嵌套事务，若是不存在一个活动的事务，都会开启一个新的事务。使用PROPAGATION_REQUIRES_NEW时，内层事务与外层事务就像两个独立的事务同样，一旦内层事务进行了提交后，外层事务不能对其进行回滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同时它须要JTA事务管理器的支持。

使用PROPAGATION_NESTED时，外层事务的回滚能够引发内层事务的回滚。而内层事务的异常并不会致使外层事务的回滚，它是一个真正的嵌套事务。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED时，须要JDBC 3.0以上驱动及1.4以上的JDK版本支持。其它的JTA TrasactionManager实现可能有不一样的支持方式。

PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 "内部" 事务。这个事务将被彻底 commited 或 rolled back 而不依赖于外部事务, 它拥有本身的隔离范围, 本身的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行。

另外一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 若是这个嵌套事务失败, 咱们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交。

因而可知, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 彻底是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 若是外部事务 commit, 潜套事务也会被 commit, 这个规则一样适用于 roll back。PROPAGATION_REQUIRED应该是咱们首先的事务传播行为。它可以知足咱们大多数的事务需求。