2、Spring 中设置事务隔离级别🍉
Spring 中事务隔离级别可以通过 @Transactional 中的 isolation 属性进行设置，具体操作如下图所示：
Ⅰ、MySQL 事务隔离级别有 4 种 🍓
1、READ UNCOMMITTED: 读未提交，也叫未提交读，该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据，而未提交的数据可能会发生回滚，因此我们把该级别读取到的数据称之为脏数据，把这个问题称之为脏读
2、READ COMMITTED: 读已提交，也叫提交读，该隔离级别的事务能读取到已经提交事务的数据因此它不会有脏读问题。但由于在事务的执行中可以读取到其他事务提交的结果，所以在不同时间的相同 SQL查询中，可能会得到不同的结果，这种现象叫做不可重复读。
3、REPEATABLE READ:可重复读是MySQL 的默认事务隔离级别，它能确保同一事务多次查询的结果一致。但也会有新的问题，比如此级别的事务正在执行时，另一个事务成功的插入了某条数据，但因为它每次查询的结果都是一样的，所以会导致查询不到这条数据，自己重复插入时又失败(因为唯一约束的原因)。明明在事务中查询不到这条信息，但自己就是插入不进去，这就叫幻读(Phantom Read)。
4、SERIALIZABLE: 序列化，事务最高隔离级别，它会强制事务排序，使之不会发生冲突，从而解决了脏读、不可重复读和幻读问题，但因为执行效率低，所以真正使用的场景并不多。
| 事务隔离级别 | 脏读 | 不可重复读 | 幻读 |
| 读未提交(READ UNCOMMITTED) | √ | √ | √ |
| 读已提交(READ COMMITTED) | × | √ | √ |
| 可重复读(REPEATABLE READ) | × | × | √ |
| 串行化(SERIALIZABLE) | × | × | × |
脏读:一个事务读取到了另一个事务修改的数据之后，后一个事务又进行了回滚操作，从而导致第一个事务读取的数据是错误的。
不可重复读:一个事务两次查询得到的结果不同，因为在两次查询中间，有另一个事务把数据修0改了。
幻读:一个事务两次查询中得到的结果集不同，因为在两次查询中另一个事务有新增了一部分数据。
在数据库中通过以下 SQL 查询全局事务隔离级别和当前连接的事务隔离级别：
select @@global.tx_isolation,@@tx_isolation;
以上 SQL 的执⾏结果如下：
Ⅱ、Spring 事务隔离级别有 5 种🍓
而Spring 中事务隔离级别包含以下 5 种：
- Isolation.DEFAULT：以连接的数据库的事务隔离级别为主。
- Isolation.READ_UNCOMMITTED：读未提交，可以读取到未提交的事务，存在脏读。
- Isolation.READ_COMMITTED：读已提交，只能读取到已经提交的事务，解决了脏读，存在不可重复读。
- Isolation.REPEATABLE_READ：可重复读，解决了不可重复读，但存在幻读（MySQL默认级别）。
- Isolation.SERIALIZABLE：串行化，可以解决所有并发问题，但性能太低。
从上述介绍可以看出，相⽐于 MySQL 的事务隔离级别，Spring 的事务隔离级别只是多了一个
Isolation.DEFAULT（以数据库的全局事务隔离级别为主）。
Spring 中事务隔离级别只需要设置 @Transactional ⾥的 isolation 属性即可，具体实现代码如下
@RequestMapping("/save") @Transactional(isolation = Isolation.SERIALIZABLE) public Object save(UserInfo user) { // 业务实现 }
四、Spring 事务传播机制🍭
1、事务传播机制是什么？🍉
Spring 事务传播机制定义了多个包含了事务的方法，相互调用时，事务是如何在这些方法间进行传递的。
2、为什么需要事务传播机制？🍉
事务隔离级别是保证多个并发事务执行的可控性的（稳定性的），而事务传播机制是保证⼀个事务在多个调用方法间的可控性的（稳定性的）。
例子：像新冠病毒⼀样，它有不同的隔离方式（酒店隔离还是居家隔离），是为了保证疫情可控，然而在每个人的隔离过程中，会有很多个执行的环节，比如酒店隔离，需要负责人员运送、物品运送、消杀原生活区域、定时核算检查和定时送餐等很多环节，而事务传播机制就是保证⼀个事务在传递过程中是可靠性的，回到本身案例中就是保证每个人在隔离的过程中可控的。
事务隔离级别解决的是多个事务同时调用⼀个数据库的问题，如下图所示：
而事务传播机制解决的是⼀个事务在多个节点（方法）中传递的问题，如下图所示：
3、事务传播机制有哪些？🍉
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 类：
以情侣关系为例来理解以上分类：
4、Spring 事务传播机制使用和各种场景演示🍉
Ⅰ、支持当前事务（REQUIRED）🍓
以下代码实现中，先开启事务先成功插入一条用户数据，然后再执行日志报错，而在日志报错是发生了异常，观察 propagation = Propagation.REQUIRED 的执行结果。
@Autowired private UserService userService; @Autowired private LogService logService; @Transactional// 声明式事务（自动提交） @RequestMapping("/insert") public Integer insert(UserInfo userInfo) { // 非空效验 if (userInfo == null || !StringUtils.hasLength(userInfo.getUsername()) || !StringUtils.hasLength(userInfo.getPassword())) { return 0; } // 添加用户 int result = userService.add(userInfo); if (result>0){ //日志 logService.add(); } /*try { int num = 10 / 0; } catch (Exception e) { System.out.println(e.getMessage()); *//*throw e;*//* TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); }*/ return result; }
UserService 实现代码如下：
@Service public class UserService { @Autowired private UserMapper userMapper; @Transactional(propagation = Propagation.REQUIRED) public Integer add(UserInfo userInfo) { int result = userMapper.add(userInfo); System.out.println("用户添加：" + result); return result; } }
LogService 实现代码如下：
@RestController public class LogService { //捣乱，设置一个算数异常 @Transactional(propagation = Propagation.REQUIRED) public int add() { int num = 10 / 0; return 1; } }
执行结果：程序报错，数据库没有插入任何数据。
执行了SQL语句，都是数据库中没有添加新用户，事务回滚了
执行流程描述
- UserService 中的保存方法正常执行完成。
- LogService 保存日志程序报错，因为使用的是 Controller 中的事务，所以整个事务回滚。
- 数据库中没有插入任何数据，也就是步骤1中的用户插入方法也回滚了。
Ⅱ、不支持当前事务（REQUIRES_NEW）🍓
UserController 类中的代码不变，将添加用户和添加日志的方法修改为 REQUIRES_NEW 不支持当前事务，重新创建事务，观察执行结果：
@RestController public class UserController { @Resource private UserService userService; @Resource private LogService logService; @RequestMapping("/save") @Transactional(propagation = Propagation.REQUIRED) public Object save(UserInfo userInfo) { // 插⼊⽤户操作 userService.save(userInfo); // 插⼊⽇志 logService.saveLog("⽤户插⼊：" + userInfo.getName()); return true; } }
UserService 实现代码如下：
@Service public class UserService { @Resource private UserMapper userMapper; @Transactional(propagation = Propagation.REQUIRED) public int save(UserInfo userInfo) { System.out.println("执⾏ save ⽅法."); return userMapper.save(userInfo); } }
LogService 实现代码如下：
@Service public class LogService { @Transactional(propagation = Propagation.REQUIRED) public int saveLog(String content) { // 出现异常 int i = 10 / 0; return 1; } }
程序执行结果：User 表中成功插入了数据，LogService 保存日志程序报错，但没影响 UserController 中的事务。
Ⅲ、不支持当前事务，NEVER 抛异常🍓
UserController 实现代码：
@RequestMapping("/save") @Transactional public Object save(UserInfo userInfo) { // 插⼊⽤户操作 userService.save(userInfo); return true; }
UserService 实现代码：
@Transactional(propagation = Propagation.NEVER) public int save(UserInfo userInfo) { System.out.println("执⾏ save ⽅法."); return userMapper.save(userInfo); }
程序执行报错，用户表未添加任何数据。
Ⅳ、NESTED 嵌套事务🍓
UserController 实现代码如下：
@RequestMapping("/save") @Transactional public Object save(UserInfo userInfo) { // 插⼊⽤户操作 userService.save(userInfo); return true }
UserService 实现代码如下：
@Transactional(propagation = Propagation.NESTED) public int save(UserInfo userInfo) { int result = userMapper.save(userInfo); System.out.println("执⾏ save ⽅法."); // 插⼊⽇志 logService.saveLog("⽤户插⼊：" + userInfo.getName()); return result; }
LogService 实现代码如下：
@Transactional(propagation = Propagation.NESTED) public int saveLog(String content) { // 出现异常 int i = 10 / 0; return 1; }
最终执行结果，用户表和日志表都没有添加任何数据。
嵌套事务和加入事务有什么区别🍓
- 整个事务如果全部执行成功，二者的结果是⼀样的。
- 如果事务执行到一半失败了，那么加入事务整个事务会全部回滚；而嵌套事务会局部回滚，不会影响上一个方法中执行的结果
