Spring事务
Spring事务
1.Spring 中事务的实现
Spring 中的事务操作分为两类：
- 编程式事务（手动写代码操作事务）。
- 声明式事务（利用注解自动开启和提交事务）。
在开始讲解它们之前，咱们先来回顾事务在 MySQL 中是如何使用的？
1.1MySQL 中的事务使用（回顾）
事务在 MySQL 有 3 个重要的操作：开启事务、提交事务、回滚事务，它们对应的操作命令如下：
-- 开启事务
start transaction
-- 提交事务
commit;
-- 回滚事务
rollback;
1.2Spring 编程式事务（了解）
Spring 手动操作事务和上⾯ MySQL 操作事务类似，它也是有 3 个重要操作步骤：
开启事务（获取事务）。
提交事务。
回滚事务。
SpringBoot 内置了两个对象，DataSourceTransactionManager ⽤来获取事务（开启事务）、提交或回滚事务的，而TransactionDefinition 是事务的属性，在获取事务的时候需要将TransactionDefinition 传递进去从而获得⼀个事务 TransactionStatus，实现代码如下：
@RestController
public class UserController {
@Resource
private UserService userService;
// JDBC 事务管理器
@Resource
private DataSourceTransactionManager dataSourceTransactionManager;
// 定义事务属性
@Resource
private TransactionDefinition transactionDefinition;
@RequestMapping("/sava")
public Object save(User user) {
// 开启事务
TransactionStatus transactionStatus = dataSourceTransactionManager
.getTransaction(transactionDefinition);
// 插⼊数据库
int result = userService.save(user);
// 提交事务
dataSourceTransactionManager.commit(transactionStatus);
// // 回滚事务
// dataSourceTransactionManager.rollback(transactionStatus);
return result;
}
}
从上述代码可以看出，以上代码虽然可以实现事务，但操作也很繁琐，有没有更简单的实现方法呢？请看下面声明式事务
1.3 Spring 声明式事务（自动）
声明式事务的实现很简单，只需要在需要的方法上添加@Transactional 注解就可以实现了，无需手动开启事务和提交事务，进入方法时自动开启事务，方法执行完会自动提交事务，如果中途发生了没有处理的异常会自动回滚事务，具体实现代码如下：
@RequestMapping("/save")
@Transactional
public Object save(User user) {
int result = userService.save(user);
return result;
}
接下来使用以下代码，分别设置 @Transactional 注解和不设置 @Transactional，观察它们的执行区别：
1.3.1
@Transactional 作用范围
@Transactional 可以用来修饰方法或类：
修饰方法时：需要注意只能应用到 public 方法上，否则不生效。推荐此种用法。
修饰类时：表明该注解对该类中所有的 public 方法都生效。
1.3.2 @Transactional 参数说明
1.3.3@Transactional 工作原理
@Transactional 是基于 AOP 实现的，AOP 又是使用动态代理实现的。如果目标对象实现了接口，默认情况下会采用 JDK 的动态代理，如果用标对象没有实现了接口,会使用 CGLIB 动态代理。@Transactional 在开始执行业务之前，通过代理先开启事务，在执行成功之后再提交事务。如果中途遇到的异常，则回滚事务。
2.事务隔离级别
2.1事务特性回顾
事务有4 大特性（ACID），原子性、持久性、⼀致性和隔离性，具体概念如下：
原子性：⼀个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个
事务从来没有执行过⼀样。
⼀致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工
作。
持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不⼀致。事务隔离分为不同级别，包括读未提交（Readuncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）
⽽这 4 种特性中，只有隔离性（隔离级别）是可以设置的
为什么要设置事务的隔离级别？
设置事务的隔离级别是用来保障多个并发事务执行更可控，更符合操作者预期的
什么是可控呢？
比如近几年比较严重的新冠病毒，我们会把直接接触到确证病例的⼈员隔离到酒店，而把间接接触者（和直接接触着但未确诊的人）隔离在自己的家中，也就是针对不同的人群，采取不同的隔离级别，这种隔离方式就和事务的隔离级别类似，都是采取某种行动让某个事件变的“更可控”。而事务的隔离级别就是为了防止，其他的事务影响当前事务执行的⼀种策略
2.2 Spring 中设置事务隔离级别
Spring 中事务隔离级别可以通过 @Transactional 中的 isolation 属性进行设置，具体操作如下图所示：
2.2.1MySQL 事务隔离级别有 4 种
- READ UNCOMMITTED：读未提交，也叫未提交读，该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据，而未提交的数据可能会发生回
滚，因此我们把该级别读取到的数据称之为脏数据，把这个问题称之为脏读。 - READ COMMITTED：读已提交，也叫提交读，该隔离级别的事务能读取到已经提交事务的数据，因此它不会有脏读问题。但由于在事务的执行中可以读取到其他事务提交的结果，所以在不同时间
的相同 SQL 查询中，可能会得到不同的结果，这种现象叫做不可重复读。 - REPEATABLE READ：可重复读，是 MySQL 的默认事务隔离级别，它能确保同⼀事务多次查询的结果⼀致。但也会有新的问题，比如此级别的事务正在执行时，另⼀个事务成功的插⼊了某条数据，但因为它每次查询的结果都是⼀样的，所以会导致查询不到这条数据，自己重复插入时又失败（因为唯⼀约束的原因）。明明在事务中查询不到这条信息，但自己就是插入不进去，这就叫幻读（Phantom Read）。
- SERIALIZABLE：序列化，事务最高隔离级别，它会强制事务排序，使之不会发生冲突，从而解决了脏读、不可重复读和幻读问题，但因为执行效率低，所以真正使用的场景并不多
脏读：⼀个事务读取到了另⼀个事务修改的数据之后，后⼀个事务又进行了回滚操作，从而导致第⼀个事务读取的数据是错误的。
不可重复读：⼀个事务两次查询得到的结果不同，因为在两次查询中间，有另⼀个事务把数据修改了。
幻读：⼀个事务两次查询中得到的结果集不同，因为在两次查询中另⼀个事务有新增了⼀部分数据
2.2.2Spring 事务隔离级别有 5 种
- Isolation.DEFAULT：以连接的数据库的事务隔离级别为主。
- Isolation.READ_UNCOMMITTED：读未提交，可以读取到未提交的事务，存在脏读。
- Isolation.READ_COMMITTED：读已提交，只能读取到已经提交的事务，解决了脏读，存在不可重复读。
- Isolation.REPEATABLE_READ：可重复读，解决了不可重复读，但存在幻读（MySQL默认级别）。
- Isolation.SERIALIZABLE：串行化，可以解决所有并发问题，但性能太低。
从上述介绍可以看出，相比于 MySQL 的事务隔离级别，Spring 的事务隔离级别只是多了⼀个Isolation.DEFAULT（以数据库的全局事务隔离级别为主）。
3.异常情况下不会进行事务回滚
以下代码就不会回滚，因为Transactional是基于AOP实现的，AOP又是动态代理，下面这段代码在代码内部自己捕获到了异常，自己捕获异常之后交给了代理，代理就以为这个代码没问题
@RestController
public class UserController {
@Resource
private UserService userService;
@RequestMapping("/save")
@Transactional
public Object save(User user) {
// 插⼊数据库
int result = userService.save(user);
try {
// 执⾏了异常代码(0不能做除数)
int i = 10 / 0;
} catch (Exception e) {
}
return result;
}
}
事务不会自动回滚解决方案
解决方案1：对于捕获的异常，事务是会自动回滚的，因此解决方案1就是可以将异常重新抛出，具体实现如下
@RequestMapping("/save")
@Transactional(isolation = Isolation.SERIALIZABLE)
public Object save(User user) {
// 插⼊数据库
int result = userService.save(user);
try {
// 执⾏了异常代码(0不能做除数)
int i = 10 / 0;
} catch (Exception e) {
System.out.println(e.getMessage());
// 将异常重新抛出去
throw e;
}
return result;
}
解决方案2：手动回滚事务，在方法中使用 TransactionAspectSupport.currentTransactionStatus() 可以得到当前的事务，然后设置回滚方法 setRollbackOnly 就可以实现回滚了
@RequestMapping("/save")
@Transactional(isolation = Isolation.SERIALIZABLE)
public Object save(User user) {
// 插⼊数据库
int result = userService.save(user);
try {
// 执⾏了异常代码(0不能做除数)
int i = 10 / 0;
} catch (Exception e) {
System.out.println(e.getMessage());
// ⼿动回滚事务
TransactionAspectSupport.currentTransactionStatus().setRollbackOnl
y();
}
return result;
}
4.事务的传播机制
4.1 事务传播机制是什么？
Spring 事务传播机制定义了多个包含了事务的方法，相互调用时，事务是如何在这些方法间进行传递的。
而事务传播机制解决的是⼀个事务在多个节点（方法）中传递的问题，如下图所示
4.2 为什么需要事务传播机制？
事务隔离级别是保证多个并发事务执行的可控性的（稳定性的），而事务传播机制是保证⼀个事务在多个调用方法间的可控性的（稳定性的）
4.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。
（嵌套事务可以认为是存档，在当前大事务的一个环节的基础上，再出来一个小事务，这个小的事务在此环节继续执行，如果成功就成功了，不成功也不影响大事务接下来的执行，相当于游戏的存档）
