关于 @Transactional 注解的基本使用,推荐看Spring 声明式事务 @Transactional(基本使用)
概述
本篇博客主要学习 @Transactional 注解当中的三个常⻅属性:
1. rollbackFor:异常回滚属性.指定能够触发事务回滚的异常类型.可以指定多个异常类型
2. Isolation:事务的隔离级别.默认值为 Isolation.DEFAULT
3. propagation:事务的传播机制.默认值为 Propagation.REQUIRED
rollbackFor(异常回滚属性)
@Transactional 默认只在遇到运⾏时异常( RuntimeException 及其子类)和Error时才会回滚,其余的异常不回滚(在首行推荐的博客中有详细的介绍)
如果我们需要所有异常都回滚,需要配置 @Transactional 注解当中的 rollbackFor 属性,通过 rollbackFor 这个属性指定出现何种异常类型时事务进⾏回滚
如下代码:
在 @Transactional 注解中设置了 rollbackFor 属性,对所有的 Exception 异常都进行回滚,此时当方法抛出的是 IOException() 时事务也会自动进行回滚
// rollbackFor 表示事务要对抛出的哪些异常进行回滚
@Transactional(rollbackFor ={Exception.class})
@RequestMapping("/registry6")
public String registry6(String userName,String password) throws IOException {
//事务执行的内容
Integer result=userService.insertUser(userName,password);
log.info("成功插入"+result+"条数据");
try {
int a=10/0;
}catch(Exception e){
throw new IOException();
}
return "注册成功";
}
Isolation(事务的隔离级别)
MySQL 事务隔离级别
SQL 标准定义了四种隔离级别, MySQL 全都⽀持.这四种隔离级别分别是:
1.读未提交(READ UNCOMMITTED):读未提交, 也叫未提交读.该隔离级别的事务可以看到其他事务中 未提交的数据. 因为其他事务未提交的数据可能会发⽣回滚,但是该隔离级别却可以读到,我们把该级别读到的数 据称之为脏数据,这个问题称之为脏读.
2. 读提交(READ COMMITTED):读已提交,也叫提交读.该隔离级别的事务能读取到已经提交事务的数据,该隔离级别不会有脏读的问题.但由于在事务的执⾏中可以读取到其他事务提交的结果,所以在不同时间的相同 SQL 查询可能会得到不同的结果,这种现象叫做不可重复读
3. 可重复读(REPEATABLE READ):事务不会读到其他事务对已有数据的修改,即使其他事务已提交.也就可以确保同⼀事务多次查询的结果⼀致,但是其他事务新插⼊的数据,是可以感知到的.这也就引发了幻读问题.可重复读,是 MySQL 的默认事务隔离级别.
幻读的概念:⽐如此级别的事务正在执⾏时,另⼀个事务成功的插⼊了某条数据,但因为它每次查询的结果都是⼀样的,所以会导致查询不到这条数据,⾃⼰重复插⼊时⼜失败(因为唯⼀约束的原因).明明在事务 中查询不到这条信息,但⾃⼰就是插⼊不进去,这个现象叫幻读.
4. 串⾏化(SERIALIZABLE):序列化,事务最⾼隔离级别.它会强制事务排序,使之不会发⽣冲突,从⽽解决了脏读,不可重复读和幻读问题,但因为执⾏效率低,所以真正使⽤的场景并不多.
事务隔离级别与存在的问题:
Spring 事务隔离级别
Spring 中事务隔离级别有 5 种:
1. Isolation.DEFAULT :以连接的数据库的事务隔离级别为主.( @Transactional 默认的隔离级别)
2. Isolation.READ_UNCOMMITTED :读未提交,对应 SQL 标准中 READ UNCOMMITTED
3. Isolation.READ_COMMITTED :读已提交,对应 SQL 标准中 READ COMMITTED
4. Isolation.REPEATABLE_READ :可重复读,对应 SQL 标准中 REPEATABLE READ
’ 5. Isolation.SERIALIZABLE :串⾏化,对应 SQL 标准中 SERIALIZABLE
Spring 中事务隔离级别可以通过 @Transactional 中的 isolation 属性进⾏设置:
@Transactional(isolation = Isolation.READ_COMMITTED)
propagation( Spring 事务传播机制)
什么是事务传播机制
事务传播机制就是:多个事务⽅法存在调⽤关系时, 事务是如何在这些⽅法间进⾏传播的.
⽐如有两个⽅法 A, B 都被 @Transactional 修饰, A ⽅法调⽤ B ⽅法 A ⽅法运⾏时,会开启⼀个事务.当 A 调⽤ B 时, B ⽅法本⾝也有事务,此时 B ⽅法运⾏时,是加⼊ A 的事务,还是创建⼀个新的事务呢?这个就涉及到了事务的传播机制.
事务的传播机制有哪些
@Transactional 注解⽀持事务传播机制的设置,通过 propagation 属性来指定传播⾏为. Spring 事务传播机制有以下 7 种(以下描述建立于子方法有事务的情况):
1. (重点)Propagation.REQUIRED :默认的事务传播级别.如果父方法存在事务,则子方法加⼊该事务.如果父方法没有事务,则子方法创建⼀个新的事务.
2. Propagation.SUPPORTS :如果父方法存在事务,则子方法加⼊该事务.如果父方法没有事务,则子方法以⾮事务的⽅式继续运⾏.
3. Propagation.MANDATORY :强制性.如果父方法存在事务,则子方法加⼊该事务.如果父方法没有事务,则子方法抛出异常.
4. (重点)Propagation.REQUIRES_NEW :创建⼀个新的事务.如果父方法存在事务,则把父方法的事务挂起.也 就是说不管父方法是否存在事务,Propagation.REQUIRES_NEW 修饰的子⽅法都会新开启⾃⼰的事务,且开启的事务相互独⽴,互不⼲扰.
5. Propagation.NOT_SUPPORTED :以⾮事务⽅式运⾏,如果父方法存在事务,则把父方法的事务挂起(不 ⽤).
6. Propagation.NEVER :以⾮事务⽅式运⾏,如果父方法前存在事务,则抛出异常.
7. Propagation.NESTED :如果父方法存在事务,则子方法创建⼀个事务作为当前事务的嵌套事务来运⾏. 如果父方法没有事务,则子方法创建⼀个新的事务.
Spring 中事务的传播机制可以通过 @Transactional 中的 propagation 属性进⾏设置:
@Transactional(propagation = Propagation.REQUIRED)