SpringMVC-@Transaction声明事务的使用

1- 事务ACID

事务由一系列操作组成的，保证所有操作整体原子执行，完整的事务满足ACID特性

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

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

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

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

2- 事务管理器

Spring并不直接管理事务，而是提供了多种事务管理器，他们将事务管理的职责委托给Hibernate或者JTA等持久化机制所提供的相关平台框架的事务来实现。

2.1- PlatformTransactionManager

org.springframework.transaction.PlatformTransactionManager是Spring事务管理器的接口，通过这个接口，Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。

PlatformTransactionManager接口

提供了获取TransactionDefinition的方法以及根据TransactionStatus相应的状态进行提交或者回滚

TransactionStatus事务状态接口

上面讲到的调用PlatformTransactionManager接口的getTransaction()的方法得到的是TransactionStatus接口的一个实现，这个接口的内容如下：

TransactionDefinition事务定义的接口

而TransactionDefinition接口内容如下：
属性：

方法：

3- TransactionDefinition接口定义的事务的五个属性

3.1- 传播行为

当事务方法被另一个事务方法调用时，必须指定事务应该如何传播，没有默认值。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行

我们可以看 org.springframework.transaction.annotation.Propagation 枚举类中定义了6个表示传播行为的枚举值：

• REQUIRED ：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
• SUPPORTS ：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
• MANDATORY ：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
• REQUIRES_NEW ：创建一个新的事务，如果当前存在事务，则把当前事务挂起。
• NOT_SUPPORTED ：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
• NEVER ：以非事务方式运行，如果当前存在事务，则抛出异常。
• NESTED ：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于 REQUIRED 。
  指定方法：通过使用 propagation 属性设置，例如：
  @Transactional(propagation = Propagation.REQUIRED)

3.2- 隔离级别

隔离级别是指若干个并发的事务之间的隔离程度，与我们开发时候主要相关的场景包括：脏读取、重复读、幻读。

并发事务引起的问题

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

• 脏读（Dirty reads）——脏读发生在一个事务读取了另一个事务改写但尚未提交的数据时。如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。
• 不可重复读（Nonrepeatable read）——不可重复读发生在一个事务执行相同的查询两次或两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间进行了更新。
• 幻读（Phantom read）——幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录。

不可重复读与幻读的区别

• 不可重复读的重点是修改:
  同样的条件, 你读取过的数据, 再次读取出来发现值不一样了 ，在一个事务中前后两次读取的结果并不一致，导致了不可重复读。
• 幻读的重点在于新增或者删除：
  同样的条件, 第1次和第2次读出来的记录数不一样
• 从总的结果来看, 似乎不可重复读和幻读都表现为两次读取的结果不一致。但如果你从控制的角度来看, 两者的区别就比较大：
  对于前者, 只需要锁住满足条件的记录。
  对于后者, 要锁住满足条件及其相近的记录。

我们可以看 org.springframework.transaction.annotation.Isolation 枚举类中定义了五个表示隔离级别的值：

• DEFAULT ：这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是： READ_COMMITTED ，Mysql为REPEATABLE_READ。
• READ_UNCOMMITTED ：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读和不可重复读，因此很少使用该隔离级别。
• READ_COMMITTED ：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值。
• REPEATABLE_READ ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。即使在多次查询之间有新增的数据满足该查询，这些新增的记录也会被忽略。该级别可以防止脏读和不可重复读。
• SERIALIZABLE ：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。
  指定方法：通过使用 isolation 属性设置，例如：
  @Transactional(isolation = Isolation.DEFAULT)

3.3- 只读

事务的第三个特性是它是否为只读事务。如果事务只对后端的数据库进行该操作，数据库可以利用事务的只读特性来进行一些特定的优化。通过将事务设置为只读，你就可以给数据库一个机会，让它应用它认为合适的优化措施。

3.4- 事务超时

为了使应用程序很好地运行，事务不能运行太长的时间。因为事务可能涉及对后端数据库的锁定，所以长时间的事务会不必要的占用数据库资源。事务超时就是事务的一个定时器，在特定时间内事务如果没有执行完毕，那么就会自动回滚，而不是一直等待其结束。

3.5- 回滚规则

事务五边形的最后一个方面是一组规则，这些规则定义了哪些异常会导致事务回滚而哪些不会。默认情况下，事务只有遇到运行期异常Unchecked时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行为是一致的）
但是你可以声明事务在遇到特定的检查型异常时像遇到运行期异常那样回滚。同样，你还可以声明事务遇到特定的异常不回滚，即使这些异常是运行期异常。

4- Spring Boot 基于声明式注解事务使用示例

在Spring Boot中，当我们使用了spring-boot-starter-jdbc或spring-boot-starter-data-jpa依赖的时候，框 架会自动默认分别注入DataSourceTransactionManager或JpaTransactionManager。所以我们不需要任何额外 配置就可以用@Transactional注解进行事务的使用。关于事务管理器，不管是JPA还是JDBC等都实现自接口 PlatformTransactionManager 如果你添加的是 spring-boot-starter-jdbc 依赖，框架会默认注入 DataSourceTransactionManager 实例。如果你添加的是 spring-boot-starter-data-jpa 依赖，框架会默认注入 JpaTransactionManager 实例。

4.1- 事务管理两种方式

spring支持编程式事务管理和声明式事务管理两种方式。

1. 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。

2. 声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。

4.2- 单事务管理开启与配置

在启动类中配置事务管理器

1. 默认事务管理器，只需开启事务管理器即可，不需显示的配置

2. 显示的指明事务管理器

如果你项目做的比较大，添加的持久化依赖比较多，我们还是会选择人为的指定使用哪个事务管理器

在Spring容器中，我们手工注解@Bean 将被优先加载，框架不会重新实例化其他的 PlatformTransactionManager 实现类。

4.3- 多事务管理器的配置

对于同一个工程中存在多个事务管理器进行配置

启动类实现TransactionManagementConfigurer接口，通过@Bean注解注入两个事务管理器，实现annotationDrivenTransactionManager接口方法，指定value缺省值情况下提供的默认事务管理器，如下：

注：
如果Spring容器中存在多个 PlatformTransactionManager 实例，并且没有实现接口 TransactionManagementConfigurer 指定默认值，在我们在方法上使用注解 @Transactional 的时候，就必须要用value指定，如果不指定，则会抛出异常。

4.4- @Transaction 注解使用的注意事项

@Transactional属性

noRollback示例

@Transactional 可以作用于接口、接口方法、类以及类方法上。当作用于类上时，该类的所有 public 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。

最佳实践：

• 虽然 @Transactional 注解可以作用于接口、接口方法、类以及类方法上，但是 Spring 建议不要在接口或者接口方法上使用该注解，因为这只有在使用基于接口的代理时它才会生效。

• @Transactional 注解应该只被应用到 public 方法上，这是由 Spring AOP 的本质决定的。如果你在 protected、private 或者默认可见性的方法上使用 @Transactional 注解，这将被忽略，也不会抛出任何异常。

• 默认情况下，只有来自外部的方法调用才会被AOP代理捕获，也就是，类内部方法调用本类内部的其他方法并不会引起事务行为，即使被调用方法使用@Transactional注解进行修饰。

事务异常排查列表：

1. 数据库本身是否支持事务，如mysql的myisam引擎就不支持事务
2. 多数据源，是否指定了正确的事务管理器
3. 数据源配置是否正确（MyBatis的SqlSessionFactoryBean引用的数据源与DataSourceTransactionManager引用的数据源是否一致）
4. 私有方法不会生效事务（AOP默认不代理私有方法，也不会抛出异常）
5. 被调用方法不会生效事务（this指针调用方法，并没有使用AOP代理来执行方法）
6. 不指明回滚的异常，方法内用户抛出的checked异常不会生效回滚（默认只有unchecked异常发生回滚）

MyBatis自动参与到spring事务管理中，无需额外配置，只要org.mybatis.spring.SqlSessionFactoryBean引用的数据源与DataSourceTransactionManager引用的数据源一致即可，否则事务管理会不起作用。

@Transaction示例

方法上注解属性会覆盖类注解上的相同属性

事务管理器保证事务方法内的SQL在同一个SqlSession中，相当于：

参考链接
Spring声明式事务为何不回滚