Spring事务管理

什么是事务

事务是一系列的动作，它们综合在一起才是一个完整的工作单元，这些动作必须全部完成，如果有一个失败的话，那么事务就会回滚到最开始的状态，仿佛什么都没发生过一样。在企业级应用程序开发中，事务管理必不可少的技术，用来确保数据的完整性和一致性。

事务有四个特性：ACID

• 原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。

• 一致性（Consistency）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏。

• 隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。

• 持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中。

核心接口

Spring事务管理的实现有许多细节，如果对整个接口框架有个大体了解会非常有利于我们理解事务，下面通过讲解Spring的事务接口来了解Spring实现事务的具体策略。
Spring事务管理涉及的接口的联系如下：

事务管理器

Spring并不直接管理事务，而是提供了多种事务管理器，他们将事务管理的职责委托给Hibernate或者JTA等持久化机制所提供的相关平台框架的事务来实现。Spring事务管理器的接口是org.springframework.transaction.PlatformTransactionManager，通过这个接口，Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。此接口的内容如下：

public interface PlatformTransactionManager()...{  
    // 由TransactionDefinition得到TransactionStatus对象
    TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException;
    // 提交
    Void commit(TransactionStatus status) throws TransactionException;  
    // 回滚
    Void rollback(TransactionStatus status) throws TransactionException;  
}

传播行为

事务的第一个方面是传播行为（propagation behavior）。当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。Spring定义了七种传播行为：

• PROPAGATION_REQUIRED

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

• PROPAGATION_SUPPORTS

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

• PROPAGATION_MANDATORY

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

• PROPAGATION_REQUIRED_NEW

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

• PROPAGATION_NOT_SUPPORTED

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

• PROPAGATION_NEVER

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

• PROPAGATION_NESTED

表示如果当前已经存在一个事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在，那么其行为与PROPAGATION_REQUIRED一样。注意各厂商对这种传播行为的支持是有所差异的。可以参考资源管理器的文档来确认它们是否支持嵌套事务

隔离级别

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

• 脏读（Dirty reads）——脏读发生在一个事务读取了另一个事务改写但尚未提交的数据时。如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。

• 不可重复读（Nonrepeatable read）——不可重复读发生在一个事务执行相同的查询两次或两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间进行了更新。

• 幻读（Phantom read）——幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录。

不可重复读与幻读的区别：不可重复读是修改，幻读是添加和删除

分为以下五个隔离级别：

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

• ISOLATION_READ_UNCOMMITTED（读取未提交内容）：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读

• ISOLATION_READ_COMMITTED（读取提交内容）：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生

• ISOLATION_REPEATABLE_READ（可重读，mysql默认）：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生

• ISOLATION_SERIALIZABLE（可串行化）：最高的隔离级别，完全服从ACID的隔离级别，写操作完全加锁，其他读也要等待，确保阻止脏读、不可重复读以及幻读，也是最慢的事务隔离级别，因为它通常是通过完全锁定事务相关的数据库表来实现的

隔离级别	读数据一致性	脏读	不可重复读	幻读
未提交读（Read uncommitted）	最低级别，只能保证不读取物理上损坏的数据	是	是	是
已提交度（Read committed）	语句级	否	是	是
可重复读（Repeatable read）	事务级	否	否	是
可序列化（Serializable）	最高级别，事务级	否	否	否

编程式事务

// 定义一个某个框架平台的TransactionManager，如JDBC、Hibernate
DataSourceTransactionManager dataSourceTransactionManager = new DataSourceTransactionManager();
// 设置数据源
dataSourceTransactionManager.setDataSource(this.getJdbcTemplate().getDataSource());
// 定义事务属性
DefaultTransactionDefinition transDef = new DefaultTransactionDefinition();
// 设置传播行为属性
transDef.setPropagationBehavior(DefaultTransactionDefinition.PROPAGATION_REQUIRED);
// 获得事务状态
TransactionStatus status = dataSourceTransactionManager.getTransaction(transDef);
try {
    // 数据库操作：提交
    dataSourceTransactionManager.commit(status);
} catch (Exception e) {
    // 数据库操作：回滚
    dataSourceTransactionManager.rollback(status);
}

常见问题

• @Transactional不生效的原因

在 Spring 的 AOP 代理下，只有目标方法由外部调用，目标方法才由 Spring 生成的代理对象来管理，这会造成一个自调用问题。若同一个类中的其他没有@Transactional 注解的方法内部调用有@Transactional 注解的方法，有@Transactional 注解的方法的事务就会被忽略，不会发生回滚。

• A方法中，编程式事务与声明式事务融为一个事务，但是声明式事务获取不到编程式事务提交的内容

因为A方法被同类下的B方法（有注解声明式事务）调用，则会出现这种情况

• A声明式事务中嵌套B声明式事务，B执行创建之后，A获取不到B创建的数据

整个线程没结束，A、B声明式事务都没提交

• Transaction rolled back because it has been marked as rollback-only

在嵌套事务中，A套B，当B出现异常回滚时，A却try-catch了B的异常，导致B事务rollback，A却commit，则会出现这个异常

void method1(){
    try{
        method2()
    }catch(...){
        xxx
    }
}

void method2(){
    throw new Exception();
}

解决方法

在抛出异常的最原始地方处理异常，即在spring捕获到异常之前处理掉

• A声明式事务中嵌套B声明式事务，B事务获取不到A事务的内容

因为B的传播行为设置为PROPAGATION_REQUIRED_NEW，则B事务中获取不到A事务的内容

参考文献

• demo
• Spring事务管理（详解+实例）