事务
Spring 中的事务操作分为两类:
- 编程式事务(⼿动写代码操作事务)。
- 声明式事务(利⽤注解⾃动开启和提交事务)。
本文主要讲使用起来更加简单方便的声明式事务。
1. Spring 声明式事务
声明式事务的实现很简单,只需要在需要的⽅法上添加 @Transactional 注解就可以实现了,⽆需⼿动开启事务和提交事务,进⼊⽅法时⾃动开启事务,⽅法执⾏完会⾃动提交事务,如果中途发⽣了没有处理的异常会⾃动回滚事务,具体实现代码如下:
在 Controller 中:
@Transactional
@RequestMapping("/add")
public Integer add(@RequestBody User user){
int result = userService.add(user);
int i = 10 / 0;
return result;
}
进行测试:
查看控制台打印的日志:由图可以看出已经插入成功
但是查看数据库:由图可以看出数据库中并没有,说明回滚了
但是将 @Transactional 注解去掉, 再次进行测试发现会插入成功
@RequestMapping("/add")
public Integer add(@RequestBody User user){
int result = userService.add(user);
int i = 10 / 0;
return result;
}
2. @Transactional 作用范围
@Transactional 可以⽤来修饰⽅法或类:
修饰⽅法时:需要注意只能应⽤到 public ⽅法上,否则不⽣效。推荐此种⽤法。
修饰类时:表明该注解对该类中所有的 public ⽅法都⽣效。
为什么 @Transactional 只能应用到 public 方法上 ?
这限制只能在公共方法上使用@Transactional是由 Spring 的事务管理机制所决定的。
Spring 的事务管理基于代理模式实现。Spring 使用代理来包装目标对象,以便能够在方法执行前后添加事务管理逻辑。 Spring 支持两种主要类型的代理:JDK 动态代理和 CGLIB 代理。
-
JDK 动态代理: 这种代理方式要求目标对象实现一个接口。在运行时,Spring创建一个代理对象,该代理对象实现了与目标对象相同的接口。当你调用代理对象的方法时,代理会在方法调用前后添加事务处理逻辑。因为 JDK 动态代理只能代理接口,所以只有公共方法才能出现在接口中,因此只有公共方法才能够被@Transactional注解代理。
-
CGLIB 代理: CGLIB 代理是另一种代理方式,可以代理没有实现接口的类。CGLIB 通过生成一个子类来实现代理。然而,CGLIB 代理也有限制,它不能代理被声明为 final 的类和方法。它可以代理非公共方法,但在Spring中,通常首选使用JDK动态代理,因为它更符合接口隔离原则。
因此,@Transactional 注解通常只能用于公共方法,因为Spring事务管理的代理机制所限制。如果需要在非公共方法上使用事务管理,可以考虑使用CGLIB代理或者通过其他手动方式实现事务管理。
3. @Transactional 参数说明
参数 | 作用 |
---|---|
value | 当配置了多个事务管理器时,可以使用该属性指定选择哪个事务管理器 |
transactionManager | 当配置多个事务管理器时,可以使用该属性指定选择哪个事务管理器 |
propagation | 事务的传播行为,默认为 Propagation.REQUIRED |
isolation | 事务的隔离级别,默认为 Propagation.DEFAULT |
timeout | 事务的超时时间, 默认值为 -1,如果超过该时间限制但事务还没完成,则自动回滚事务 |
readOnly | 指定事务是否为只读事务,默认值为 false, 为了忽略那些不需要事务的方法,比如读取数据,可以设置 read-only 为 true |
rollbackFor | 用于指定能够触发事务回滚的异常类型,可以指定多个异常类型 |
rollbackForClassName | 用于指定能够触发事务回滚的异常类型,可以指定多个异常类型 |
noRollbackFor | 抛出指定的异常类型,不会滚事务,也可以指定多个异常类型 |
noRollbackForClassName | 抛出指定的异常类型,不会滚事务,也可以指定多个异常类型 |
注意 @Transactional 在异常被捕获的情况下,不会进⾏事务⾃动回滚.
比如上面的那段代码:对异常进行捕获
@Transactional
@RequestMapping("/add")
public Integer add(@RequestBody User user){
int result = userService.add(user);
try {
int i = 10 / 0;
} catch (Exception e) { // 对异常进行了捕获
System.out.println(e.getMessage());
}
return result;
}
进行测试,查看数据库发现数据插入成功。
事务不会⾃动回滚解决⽅案
- 解决⽅案1:将异常重新抛出
@Transactional
@RequestMapping("/add")
public Integer add(@RequestBody User user){
int result = userService.add(user);
try {
int i = 10 / 0;
} catch (Exception e) {
System.out.println(e.getMessage());
throw e; // 将异常重新抛出,事务就会回滚
}
return result;
}
- 解决⽅案2:⼿动回滚事务,在⽅法中使⽤ TransactionAspectSupport.currentTransactionStatus() 可以得到当前的事务,然后设置回滚⽅法 setRollbackOnly 就可以实现回滚了。
@Transactional
@RequestMapping("/add")
public Integer add(@RequestBody User user){
int result = userService.add(user);
try {
int i = 10 / 0;
} catch (Exception e) {
System.out.println(e.getMessage());
// 手动进行事务回滚
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}
return result;
}
4. @Transactional 工作原理
@Transactional 是基于 AOP 实现的,AOP ⼜是使⽤动态代理实现的。如果⽬标对象实现了接⼝,默认情况下会采⽤ JDK 的动态代理,如果⽬标对象没有实现了接⼝,会使⽤ CGLIB 动态代理。
@Transactional 在开始执⾏业务之前,通过代理先开启事务,在执⾏成功之后再提交事务。如果中途遇到了异常,则回滚事务。
@Transactional 具体执⾏细节如下图所示:
5. 事务隔离级别
事务特性:
ACID: 原⼦性、⼀致性、隔离性和持久性。
-
原⼦性(Atomicity):⼀个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执⾏过程中发⽣错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执⾏过⼀样。
-
⼀致性(Consistency):在事务开始之前和事务结束以后,数据库的完整性没有被破坏。
-
隔离性(Isolation):数据库允许多个并发事务同时对其数据进⾏读写和修改的能⼒,隔离性可以防⽌多个事务并发执⾏时由于交叉执⾏⽽导致数据的不⼀致。事务隔离分为不同级别,包括读未提交(Readuncommitted)、读提交(read committed)、可重复读(repeatable read)和串⾏化(Serializable)。
-
持久性 (Durability):事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
这 4 种特性中,只有隔离性(隔离级别)是可以设置的。
设置事务的隔离级别是⽤来保障多个并发事务执⾏更可控,为了防⽌其他的事务影响当前事务执⾏的⼀种策略,更符合操作者预期的。
6. Spring 中设置事务隔离级别
Spring 中事务隔离级别可以通过 @Transactional 中的 isolation 属性进⾏设置,具体操作如下图所示:
7. MySQL 事务隔离级别
(关于 MySQL 事务的详细信息可见 MySQL 事务详解)
MySQL 事务隔离级别有 4 种:
- READ UNCOMMITTED:读未提交,也叫未提交读,该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据,⽽未提交的数据可能会发⽣回滚,因此我们把该级别读取到的数据称之为脏数据,把这个问题称之为脏读。
- READ COMMITTED:读已提交,也叫提交读,该隔离级别的事务能读取到已经提交事务的数据,因此它不会有脏读问题。但由于在事务的执⾏中结果可能被其他事务修改了,所以在不同时间的相同 SQL 查询中,可能会得到不同的结果,这种现象叫做不可重复读。
- REPEATABLE READ:可重复读,是 MySQL 的默认事务隔离级别,它能确保同⼀事务多次查询的结果⼀致。但也会有新的问题,⽐如此级别的事务正在执⾏时,另⼀个事务成功的插⼊了某条数据,此时再次进行读取时发现结果的条数变多了,这就叫幻读(Phantom Read)。
- SERIALIZABLE:序列化,事务最⾼隔离级别,它会强制事务排序,使之不会发⽣冲突,从⽽解决了脏读、不可重复读和幻读问题,但因为执⾏效率低,所以真正使⽤的场景并不多。
- 脏读:⼀个事务读取到了另⼀个事务修改的数据之后,后⼀个事务⼜进⾏了回滚操作,从⽽导致第⼀个事务读取的数据是错误的。
- 不可重复读:⼀个事务两次查询得到的结果不同,因为在两次查询中间,有另⼀个事务把数据修改了。
- 幻读:⼀个事务两次查询中得到的结果集不同,因为在两次查询中另⼀个事务有新增了⼀部分数据。
8. Spring 事务隔离级别
Spring 中事务隔离级别包含以下 5 种:
- Isolation.DEFAULT:以连接的数据库的事务隔离级别为主。
- Isolation.READ_UNCOMMITTED:读未提交,可以读取到未提交的事务,存在脏读。
- Isolation.READ_COMMITTED:读已提交,只能读取到已经提交的事务,解决了脏读,存在不可重复读。
- Isolation.REPEATABLE_READ:可重复读,解决了不可重复读,但存在幻读(MySQL默认级别)。
- Isolation.SERIALIZABLE:串⾏化,可以解决所有并发问题,但性能太低。
相⽐于 MySQL 的事务隔离级别,Spring 的事务隔离级别只是多了⼀个 Isolation.DEFAULT(以数据库的全局事务隔离级别为主)。
注意:
- 当 Spring 中设置的事务隔离级别与连接的数据库隔离级别冲突时,以 Spring 为准。
- Spring 中事务隔离级别机制的实现依赖于要连接的数据库,以要连接的数据库支持事务隔离级别为基础。