Spring 事务

1. 简介

事务是数据库操作最基本单元，逻辑上一组操作，要么都成功，如果有一个失败所有操作都失败。

在现实世界中，最常见的与事务相关的例子可能就是银行转账了。假设我们需要将 1000 元从 A 账户中转到 B 账户中，这个转账操作共涉及了以下两个操作。

1. 从 A 账户中扣除 1000 元；
2. 往 B 账户中存入 1000 元。

如果 A 账户成功地扣除了 1000 元，但向 B 账户存入时失败的话，那么我们将凭空损失 1000 元；如果 A 账户扣款时失败，但却成功地向 B 账户存入 1000 元的话，我们的账户就凭空多出了 1000 元，那么银行就会遭受损失。因此我们必须保证事务中的所有操作要么全部成功，要么全部失败。

为了保证事务是正确可靠的，在数据库进行写入或者更新操作时，就必须得表现出 ACID 的 4 个重要特性：

• 原子性（Atomicity）：一个事务是一个不可分割的工作单位，事务中包括的动作要么都做要么都不做。
• 一致性（Consistency）：事务必须保证数据库从一个一致性状态变到另一个一致性状态，一致性和原子性是密切相关的。
• 隔离性（Isolation）：一个事务的执行不能被其它事务干扰，即一个事务内部的操作及使用的数据对并发的其它事务是隔离的，并发执行的各个事务之间不能互相打扰。
• 持久性（Durability）：持久性也称为永久性，指一个事务一旦提交，它对数据库中数据的改变就是永久性的，后面的其它操作和故障都不应该对其有任何影响。

AID三个特性保证了C特性。

2. 事务隔离级别

事务隔离分为 4 种不同的级别：

• 读未提交（Read uncommitted），最低的隔离级别，允许“脏读”（dirty reads），事务可以看到其他事务“尚未提交”的修改。如果另一个事务回滚，那么当前事务读到的数据就是脏数据。
• 读已提交（read committed），一个事务可能会遇到不可重复读（Non Repeatable Read）的问题。不可重复读是指，在一个事务内，多次读同一数据，在这个事务还没有结束时，如果另一个事务恰好修改了这个数据，那么，在第一个事务中，两次读取的数据就可能不一致。
• 可重复读（repeatable read），一个事务可能会遇到幻读（Phantom Read）的问题。幻读是指，在一个事务中，第一次查询某条记录，发现没有，但是，当试图更新这条不存在的记录时，竟然能成功，并且，再次读取同一条记录，它就神奇地出现了。
• 串行化（Serializable），最严格的隔离级别，所有事务按照次序依次执行，因此，脏读、不可重复读、幻读都不会出现。虽然 Serializable 隔离级别下的事务具有最高的安全性，但是，由于事务是串行执行，所以效率会大大下降，应用程序的性能会急剧降低。如果没有特别重要的情景，一般都不会使用 Serializable 隔离级别。

• 脏读：一个未提交事务读取到另一个未提交事务的数据
• 不可重复读：一个未提交事务读取到另一提交事务修改数据
• 虚读：一个未提交事务读取到另一提交事务添加数据

3. 事务管理

Spring 支持两种事务方式，分别是编程式事务和声明式事务。在实际使用中只要以声明式事务为主。声明式事务管理有注解方式与xml 配置方式，实际使用以注解方式为主。

声明式事务将事务管理代码从业务方法中抽离了出来，在 Spring 进行声明式事务管理，底层使用 AOP 原理。

Spring 将事务管理的核心抽象为一个事务管理器（TransactionManager），它的源码只有一个简单的接口定义，属于一个标记接口，这个接口针对不同的框架提供不同的实现类。

3.1 配置

3.1.1 xml 配置方式

1. 在 spring 配置文件，开启事务注解

2. 在 service 类上面添加事务注解

• @Transactional，这个注解添加到类上面，也可以添加方法上面
• 如果把这个注解添加类上面，这个类里面所有的方法都添加事务
• 如果把这个注解添加方法上面，为这个方法添加事务

• timeout：超时时间
  • 事务需要在一定时间内进行提交，如果不提交进行回滚
• readOnly：是否只读
  • 读：查询操作，写：添加修改删除操作
  • readOnly默认值false，表示可以查询，可以添加修改删除操作
  • 设置readOnly值是true，设置成true之后，只能查询
• rollbackFor：回滚
  • 设置出现哪些异常进行事务回滚
• noRollbackFor：不回滚
  • 设置出现哪些异常不进行事务回滚

3.1.2 注解方式

除了xml 配置开启事务注解，还可以通过配置类开启事务注解。

4. 事务传播行为

当事务方法被另外一个事务方法调用时，必须指定事务应该如何传播，例如，方法可能继续在当前事务中执行，也可以开启一个新的事务，在自己的事务中执行。
声明式事务的传播行为可以通过 @Transactional 注解中的 propagation 属性来定义，比如说：

TransactionDefinition 一共定义了 7 种事务传播行为，其中PROPAGATION_REQUIRED、PROPAGATION_REQUIRES_NEW 两种传播行为是比较常用的。

PROPAGATION_REQUIRED

这也是 @Transactional 默认的事务传播行为，指的是如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。更确切地意思是：
如果外部方法没有开启事务的话，Propagation.REQUIRED 修饰的内部方法会开启自己的事务，且开启的事务相互独立，互不干扰。
如果外部方法开启事务并且是 Propagation.REQUIRED 的话，所有 Propagation.REQUIRED 修饰的内部方法和外部方法均属于同一事务 ，只要一个方法回滚，整个事务都需要回滚。

也就是说如果a方法和b方法都添加了注解，在默认传播模式下，a方法内部调用b方法，会把两个方法的事务合并为一个事务。

PROPAGATION_REQUIRES_NEW

创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部方法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部方法都会开启自己的事务，且开启的事务与外部的事务相互独立，互不干扰。

当类A中的 a 方法用默认 Propagation.REQUIRED模式，类B中的 b方法加上采用 Propagation.REQUIRES_NEW模式，然后在 a 方法中调用 b方法操作数据库，然而 a方法抛出异常后，b方法并没有进行回滚，因为Propagation.REQUIRES_NEW会暂停 a方法的事务 ，总结就是a不影响b，b影响a。

PROPAGATION_NESTED

如果当前存在事务，就在当前事务内执行；否则，就执行与 PROPAGATION_REQUIRED 类似的操作。

当类A中的 a 方法用默认 Propagation.REQUIRED模式，类B中的 b方法加上采用 Propagation.NESTED模式，然后在 在a 方法里调用 b方法操作数据库，然而 b方法抛出异常后，a方法是不的回滚 ，总结就是b不影响a，a影响b。

PROPAGATION_SUPPORTS

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

PROPAGATION_NOT_SUPPORTED

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

PROPAGATION_MANDATORY

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

PROPAGATION_NEVER

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

5. @Transaction失效场景

• propagation设置问题，会导致事务不生效，也就事务不会回滚
• rollbackFor指定事务回滚的异常类型
• 同个类中的调用被@transaction修饰的方法，会失效，因为只有当事务方法被当前类以外的代码调用，才会由spring生成的代理对象来管理。
• try catch导致失效
• 数据库不支持事务
• 作用于非public方法

作用于非public方法上，之所以会失效是因为在Spring AOP 代理时，TransactionInterceptor （事务拦截器）在目标方法执行前后进行拦截，DynamicAdvisedInterceptor（CglibAopProxy 的内部类）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法会间接调用 AbstractFallbackTransactionAttributeSource的 computeTransactionAttribute方法，获取Transactional 注解的事务配置信息。
此方法会检查目标方法的修饰符是否为 public，不是 public则不会获取@Transactional 的属性配置信息。

注意：protected、private修饰的方法上使用 @Transactional 注解，虽然事务无效，但不会有任何报错，这是我们很容犯错的一点。