【JavaEE】Spring 事务传播机制
目录✅
- 1. 事务传播机制定义
-
- 1.1 事务传播机制与事务隔离级别区别
- 2. 7大事务的传播机制
- 3. Spring 事务传播机制使用和各种场景演示
-
- 3.1 支持当前事务（REQUIRED）
- 3.2 NESTED 嵌套事务
- 3.3 不支持当前事务（REQUIRES_NEW）
- 3.4 不支持当前事务，NEVER 抛异常（存在事务，则抛出异常）
1. 事务传播机制定义
Spring 事务传播机制定义了多个包含了事务的⽅法，相互调⽤时，事务是如何在这些⽅法间进⾏传递的。
1.1 事务传播机制与事务隔离级别区别
- 事务隔离级别是保证多个并发事务执⾏的可控性的（稳定性的）（横向并列时）
- 事务传播机制是保证⼀个事务在多个调⽤⽅法间的可控性的（稳定性的）（纵向相互调用时）
事务隔离级别解决的是多个事务同时调⽤⼀个数据库的问题，如下图所示：
⽽事务传播机制解决的是⼀个事务在多个节点（⽅法）中传递的问题，如下图所示：
2. 7大事务的传播机制
Spring 事务传播机制包含以下 7 种：
Propagation.REQUIRED：默认的事务传播级别，它表示如果当前存在事务，则加⼊该事务；如果当前没有事务，则创建⼀个新的事务。（整体考虑，局部事务出问题，整体都回滚）Propagation.SUPPORTS：如果当前存在事务，则加⼊该事务；如果当前没有事务，则以⾮事务的⽅式继续运⾏。Propagation.MANDATORY：（mandatory：强制性）如果当前存在事务，则加⼊该事务；如果当前没有事务，则抛出异常。Propagation.REQUIRES_NEW：表示创建⼀个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部⽅法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部⽅法会新开启⾃⼰的事务，且开启的事务相互独⽴，互不⼲扰。Propagation.NOT_SUPPORTED：以⾮事务⽅式运⾏，如果当前存在事务，则把当前事务挂起。Propagation.NEVER：以⾮事务⽅式运⾏，如果当前存在事务，则抛出异常。Propagation.NESTED：如果当前存在事务，则创建⼀个事务作为当前事务的嵌套事务来运⾏；如果当前没有事务，则该取值等价于 PROPAGATION_REQUIRED。（局部考虑，局部事务出问题，只回滚这个局部事务，这个局部事务不会导致整体事务回滚）
以上 7 种传播⾏为，可以根据是否⽀持当前事务分为以下 3 类：
以上分类可以用“情侣”关系来帮助理解：
3. Spring 事务传播机制使用和各种场景演示
关靠以上理论理解事务困难很多，接下来就以实际场景（代码演示）为列来讲解spring事务的传播机制使用，帮助大家更好的理解并正确使用事务的7大传播机制：
3.1 支持当前事务（REQUIRED）
首先在数据库中建立两个表（user表+log表）用户表和日志记录表，来演示事务的传播机制使用：
以及这两个表对应的Java实体类（model）：
实现添加用户和添加日志的mapper和xml：
添加用户：
添加日志：
注意在写添加日志SQL时候由于表字段desc与mysql关键字desc冲突，所以要给SQL desc加上 `` 反引号（esc键下面的那个）
此时的代码调用关系如下图：
在controller中的add接口先是调用添加用户的userservice接口，在添加用户完成后调用添加日志的logservice接口（在service层调用mapper来实现SQL操作数据库）：
service层代码如下：
此时测试 REQUIRED ：
controller层代码：
给service层分别实现添加用户和添加日志的两个方法也加上此传播机制（不加也一样，默认的事务传播机制）：
访问接口：（传递用户的姓名和密码）
注意此时数据库中user表只有admin默认这一个记录，日志表为空：
代码不出所料触发了在添加日志代码时的异常：
此时观察控制台：
发现添加用户以及添加日志的SQL均执行成功
但是，观察数据库：
用户表和日志表中依旧没有刚才执行的SQL结果，也就是说事务全部都回滚了！
⽤户表和⽇志表中都没有添加任何数据，说明整个事务都回滚了。也就是说 REQUIRED 如果回滚就是
回滚所有事务，不能实现部分事务的回滚。
总结：加入当前事务 @Transactional(propagation = Propagation.REQUIRED)
当日志添加方法出现异常之后，加入事务的执行结果是：
- 用户添加成功的数据也跟着回滚了
- 日志添加数据自然也回滚了
3.2 NESTED 嵌套事务
此时在controller代码中使用嵌套事务：
在service中添加用户和添加日志的方法上也设置嵌套事务：
此时依旧在添加日志时候触发异常使事务回滚：
访问接口：
SQL也是执行成功的：
结果和上面的 REQUIRED 现象是一样的，此时我们观察数据库：
发现user表用户插入成功了，但是日志表日志依旧没有插入成功
总结：
嵌套事务： @Transactional(propagation = Propagation.NESTED)
当日志添加方法出现异常后，嵌套事务的执行结果是：
- 用户添加不受影响，添加用户成功了，添加用户事务没有回滚
- 日志添加失败了，发生了异常回滚了日志添加的事务
所以说 required 加入事务，局部事务的失败是影响整体事务的，局部失败导致整体也失败
nested 嵌套事务，局部事务的失败只影响局部事务，只会回滚局部事务，其他事务不会影响
嵌套事务只所以能够实现部分事务的回滚，是因为事务中有⼀个保存点（savepoint）的概念，嵌套事务
进⼊之后相当于新建了⼀个保存点，⽽滚回时只回滚到当前保存点，因此之前的事务是不受影响的，这
⼀点可以在 MySQL 的官⽅⽂档汇总找到相应的资料：savepoint官网文档
（相当于玩单机游戏时候的存单点（保存点savepoint），如果玩家死亡（代码异常）就会自动回到上一个存档点，所以嵌套事务能实现部分事务的回滚）
⽽ REQUIRED 是加⼊到当前事务中，并没有创建事务的保存点，因此出现了回滚就是整个事务回滚，这就是嵌套事务和加⼊事务的区别。
总结：嵌套事务（NESTED）和加⼊事务（REQUIRED ）的区别：
- 整个事务如果全部执⾏成功，⼆者的结果是⼀样的。
- 如果事务执⾏到⼀半失败了，那么加⼊事务整个事务会全部回滚；⽽嵌套事务会局部回滚，不会影
响上⼀个⽅法中执⾏的结果。
3.3 不支持当前事务（REQUIRES_NEW）
UserController 类中的代码不变，将添加⽤户和添加⽇志的⽅法修改为 REQUIRES_NEW 不⽀持当前事
务，重新创建事务，观察执⾏结果：
注意这里添加日志的代码是先触发异常，再执行添加：
程序执⾏结果：User 表中成功插⼊了数据，Log 表执⾏失败，但没影响 UserController 中的事务。
结论：不管外部⽅法（controller/add）是否开启事务，Propagation.REQUIRES_NEW 修饰的内部⽅法（添加用户和添加日志）会新开启⾃⼰的事务，且开启的事务相互独⽴，互不⼲扰。
3.4 不支持当前事务，NEVER 抛异常（存在事务，则抛出异常）
在service中设置此事务传播机制，则只要调用链中存在事务，就抛出异常，代码也不会执行成功的：
直接抛异常，数据库中也没有相应记录：
- over ~ ✨