JavaEE进阶Transactional-详解
【JavaEE进阶】@Transactional 详解
🍃前言
本篇博客的将讲述 @ 注解的使用细节 主要学习 @Transactional 注解当中的三个常见属性:
- rollbackFor:异常回滚属性.指定能够触发事务回滚的异常类型.可以指定多个异常类型
- Isolation:事务的隔离级别.默认值为 Isolation.DEFAULT
- propagation:事务的传播机制.默认为Propagation.REQUIRED
🌲rollbackFor(异常回滚属性)
🚩rollbackFor属性
源码：
@Transactional 默认只在遇到运行时异常和Error时才会回滚,非运行时异常不回滚.
即Exception的⼦类中,除了RuntimeException及其⼦类.
如果我们需要所有异常都回滚,需要来配置 @Transactional 注解当中的 rollbackFor 属性,通过 rollbackFor
这个属性指定出现何种异常类型时事务进行回滚
代码：
在上篇文章中，演示了该代码会出现运行时异常，它是继承的RuntimeEcxeption，所以会进行回滚
接下来我们把异常改为如下代码
发送请求：
观察日志：发现事务是进行提交了，并没有回滚
如果我们需要所有异常都回滚,需要来配置 过 @Transactional 注解当中的 rollbackFor 这个属性，通过rollbackFor
这个属性指定出现何种异常类型时事务进⾏回滚
指定所有异常回滚：
运行观察日志：发现事务没有提交，进行了回滚
🚩noRollbackFor属性
源码：
我们知道了rollbackFor属性是指定异常进行回滚；那么noRollbackFor指定异常不进行回滚
🎄Isolation(事务隔离级别)
我们先来看一下MySQL事务隔离级别都有那些
🚩MySQL事务的隔离级别
SQL标准定义了四种隔离级别,MySQL全都⽀持.这四种隔离级别分别是:
- 1 读未提交(READUNCOMMITTED): 读未提交,也叫未提交读.该隔离级别的事务可以看到其他事务中未提交的数据.
因为其他事务未提交的数据可能会发⽣回滚,但是该隔离级别却可以读到,我们把该级别读到的数 据称之为脏数据,这个问题称之为脏读.
- 2 读提交(READ COMMITTED): 读已提交,也叫提交读.该隔离级别的事务能读取到已经提交事务的数据
该隔离级别不会有脏读的问题.但由于在事务的执行中可以读取到其他事务提交的结果，所以在不同时间的相同 SQL 查询可能会得到不同的结果,这种现象叫做不可重复读
- 3 可重复读(REPEATABLE READ): 事务不会读到其他事务对已有数据的修改,即使其他事务已提交.也就可以确保同⼀事务多次查询的结果⼀致,但是其他事务新插⼊的数据,是可以感知到的.这也就引发了幻读问题.可重复读,是MySQL的默认事务隔离级别.
⽐如此级别的事务正在执⾏时,另⼀个事务成功的插⼊了某条数据,但因为它每次查询的结果都是⼀样的,所以会导致查询不到这条数据,自己重复插⼊时⼜失败(因为唯⼀约束的原因).明明在事务 中查询不到这条信息，但⾃⼰就是插⼊不进去,这个现象叫幻读.
- 4 串⾏化(SERIALIZABLE): 序列化,事务最⾼隔离级别.它会强制事务排序,使之不会发⽣冲突,从⽽解决了脏读,不可重复读和幻读问题,但因为执⾏效率低,所以真正使⽤的场景并不多
MySQL可重复读演示：
1
查看user_info表
2
开启两个事务
3
事务B进行插入数据，在进行提交
4
查询数据库(可以看到事务B成功的提交了数据)
5
事务A进行查询数据库(可以看到查不到上述id为12的记录，事务A是查询不到的)
6
在事务A中插入上述id为12的记录(发现也插入不了，说主键冲突了，这就叫幻读)
7
当事务A进行提交之后，在此查询就可以查询到了
2
开启两个事务
3
事务B进行插入数据，在进行提交
4
查询数据库(可以看到事务B成功的提交了数据)
5
事务A进行查询数据库(可以看到查不到上述id为12的记录，事务A是查询不到的)
6
在事务A中插入上述id为12的记录(发现也插入不了，说主键冲突了，这就叫幻读)
7
当事务A进行提交之后，在此查询就可以查询到了
🚩Spring事务隔离级别
Spring 中事务隔离级别有5 种:
源码：
- Isolation.DEFAULT :以连接的数据库的事务隔离级别为主(连接MySQL默认就是可重复读).
- Isolation.READ_UNCOMMITTED :读未提交,对应SQL标准中READ UNCOMMITTED
- Isolation.READ_COMMITTED :读已提交,对应SQL标准中READ COMMITTED
- Isolation.REPEATABLE_READ :可重复读,对应SQL标准中 REPEATABLE READ
- Isolation.SERIALIZABLE :串行化,对应SQL标准中SERIALIZABLE
Spring中事务隔离级别可以通过 @Transactional 中的 isolation 属性进行设置
🎋Spring事务传播机制
🚩什么是事务传播机制
事务传播机制就是: 多个事务⽅法存在调⽤关系时,事务是如何在这些⽅法间进⾏传播的. 比如有两个⽅法A,B都被 @Transactional 修饰,A⽅法调⽤B⽅法 A⽅法运⾏时,会开启⼀个事务.当A调⽤B时,B⽅法本⾝也有事务,此时B⽅法运⾏时,是加⼊A的事务,还是创建⼀个新的事务呢? 这个就涉及到了事务的传播机制.
⽐如公司流程管理
执⾏任务之前,需要先写执⾏⽂档,任务执⾏结束,再写总结汇报
此时A部⻔有⼀项⼯作,需要B部⻔的⽀援,此时B部⻔是直接使⽤A部⻔的⽂档,还是新建⼀个⽂档呢? 事务隔离级别解决的是多个事务同时调⽤⼀个数据库的问题
而事务传播机制解决的是⼀个事务在多个节点(方法)中传递的问题
🚩事务有哪些传播机制
@Transactional 注解⽀持事务传播机制的设置,通过propagation 属性来指定传播⾏为.
Spring 事务传播机制有以下 7
种：
- Propagation.REQUIRED :默认的事务传播级别.如果当前存在事务,则加⼊该事务.如果当前没有事务,则创建⼀个新的事务.
- Propagation.SUPPORTS : 如果当前存在事务,则加⼊该事务.如果当前没有事务,则以⾮事务的⽅式继续运⾏.
- Propagation.MANDATORY :强制性.如果当前存在事务,则加⼊该事务.如果当前没有事务,则抛出异常.
- Propagation.REQUIRES_NEW :创建⼀个新的事务.如果当前存在事务,则把当前事务挂起.也就是说不管外部方法是否开启事务, Propagation.REQUIRES_NEW 修饰的内部⽅法都会新开启自己的事务,且开启的事务相互独⽴,互不⼲扰.
- Propagation.NOT_SUPPORTED : 以⾮事务⽅式运⾏,如果当前存在事务,则把当前事务挂起(不⽤).
- Propagation.NEVER : 以⾮事务⽅式运⾏,如果当前存在事务,则抛出异常.
- Propagation.NESTED : 如果当前存在事务,则创建⼀个事务作为当前事务的嵌套事务来运⾏.如果当前没有事务,则该取值等价于PROPAGATION_REQUIRED . 可能上述理解起来有点儿抽象，这儿举个例子
⽐如⼀对新⼈要结婚了,关于是否需要房⼦
- Propagation.REQUIRED :需要有房⼦.如果你有房,我们就⼀起住,如果你没房,我们就⼀起买房.(如果当前存在事务,则加⼊该事务.如果当前没有事务,则创建⼀个新的事务)
- Propagation.SUPPORTS : 可以有房⼦. 如果你有房,那就⼀起住.如果没房,那就租房.(如果当前存在事务,则加⼊该事务.如果当前没有事务,则以⾮事务的⽅式继续运⾏)
- Propagation.MANDATORY :必须有房⼦.要求必须有房,如果没房就不结婚.(如果当前存在事务,则加⼊该事务.如果当前没有事务,则抛出异常)
- Propagation.REQUIRES_NEW :必须买新房.不管你有没有房,必须要两个⼈⼀起买房.即使有房也不住.(创建⼀个新的事务.如果当前存在事务,则把当前事务挂起)
- Propagation.NOT_SUPPORTED :不需要房.不管你有没有房,我都不住,必须租房.(以非事务⽅式运⾏,如果当前存在事务,则把当前事务挂起)
- Propagation.NEVER :不能有房⼦.(以⾮事务⽅式运⾏,如果当前存在事务,则抛出异常)
- Propagation.NESTED :如果你没房,就⼀起买房.如果你有房,我们就以房⼦为根据地,做点小⽣意.(如果如果当前存在事务,则创建⼀个事务作为当前事务的嵌套事务来运⾏.如果当前没有事务,则该取值等价于PROPAGATION_REQUIRED )
这里我们需要注意一下NESTED和REQUIRED区别
- 整个事务如果全部执⾏成功,⼆者的结果是⼀样的.
- 如果事务⼀部分执⾏成功,REQUIRED加⼊事务会导致整个事务全部回滚.NESTED嵌套事务可以实现局部回滚,不会影响上⼀个方法中执⾏的结果.
嵌套事务之所以能够实现部分事务的回滚,是因为事务中有⼀个保存点(savepoint)的概念,嵌套事务进⼊之后相当于新建了⼀个保存点,而滚回时只回滚到当前保存点
使用方法与上述两个属性使用方法是一样的，进行相应属性值设置即可
🚩Spring事务传播机制使用和各种场景演示
对于以上事务传播机制，我们重点关注以下两个就可以了：
- REQUIRED（默认值）
- REQUIRES_NEW 数据准备： user_info表和相关代码在上篇文章以准备
- 1 log_info表：
- 2 controller
- 3 service
- 4 mapper
测试：
发送请求前数据表：
发送请求：
发送请求后数据表：
测试：
发送请求前数据表：
发送请求：
发送请求后数据表：
🏀REQUIRED(加入事务)
方法调用方的代码：
被调用方的代码：
required理解：如果当前存在事务,则加⼊该事务.如果当前没有事务,则创建⼀个新的事务.
当前调用方registry是存在事务的，那么insertUser和InsertLog都会使用registry的事务，他们三个共用这一个事务。
如果当前我让insertLog报错，insertUser执行成功
insertLog代码修改：
他们三个使用的是同一个事务，那么当前insertLog会报错，进行回滚，他们三个都会进行回滚。
测试：
发送请求前数据表：
发送请求：
查看日志：全部进行了回滚，没有提交
发送请求后数据表：发现也没有插入进来
🏀REQUIRES_NEW(新建事务)
调用方代码：
被调用方代码：
requires_new理解：创建⼀个新的事务.如果当前存在事务,则把当前事务挂起.也就是说不管外部方法是否开启事务,
Propagation.REQUIRES_NEW 修饰的内部⽅法都会新开启自己的事务,且开启的事务相互独⽴,互不⼲扰.
意思就是当前代码，insertLog会有异常，进行回滚；insertUser没有异常，正确提交
测试：
发送请求前数据表：
发请求请：
查看日志：
发送请求后数据表：
注意：若只是调用方发生异常(controller)，被调用方没有异常(insertLog,
insertUser)，则被调用方开启新的事务，会正确的进行提交，不会回滚。
🏀NEVER(不支持当前事务,抛异常)
调用方代码：
被调用方代码：
never理解：以⾮事务⽅式运⾏,如果当前存在事务,则抛出异常.
意思就是insertLog必须以非事务的方式运行，若有事务过来了，就会报错；那么当前registry是有事务的，所以insertLog就会报错，insertUser则正确提交。
测试：
发送请求前数据表：
发送求情：
查看日志：
发送请求后数据表：
🏀NESTED(嵌套事务)
与required比较：
调用方代码：
被调用方代码：
上述我们演示了required，若调用方有事务，则被调用方使用调用方的事务，当发生异常时，会进行回滚。那么方法成功时事务全部提交。
- 方法出现异常：事务全部回滚
- 方法都执行成功：事务全部提交
改成NESTED：
方法成功的情况：
调用方代码：
被调用方代码：
发送请求前数据表：
发送请求：
查看日志：
发送请求后数据表：
发现上述事务全部提交
事务异常的情况：
修改insertLog代码：
发送请求前数据表：
发送请求：
查看日志：发现日志没有提交操作
发送请求后数据表：发现两个都没有进行插入，事务全部回滚
结论：
- 方法全部执行成功：事务全部提交
- 方式出现异常：事务全部回滚
被调用方代码：
发送请求前数据表：
发送请求：
查看日志：
发送请求后数据表：
发现上述事务全部提交
事务异常的情况：
修改insertLog代码：
发送请求前数据表：
发送请求：
查看日志：发现日志没有提交操作
发送请求后数据表：发现两个都没有进行插入，事务全部回滚
结论：🏀NESTED和REQUIRED有什么区别？
经过上述发现，NESTED和REQUIRED的结论好像都是一样的，那他们有什么区别？
我们可以简单的理解为
REQUIRED他们使用的是同一事务，要么都提交，要么都回滚
NESTED理解为父子事务，子事务处理成功了，父事务不受影响；子事务处理不好，父事务受牵连
我们就需要对子事务进行处理：
代码：
我们知道，NESTED属于嵌套事务，那么insertLog和insertUser都属于嵌套事务，由于呢insertLog中发生了异常，导致影响到了父事务(registry)，那么也就影响到了insertUser，全部回滚了；此时呢当insertLog出现异常了自己进行了回滚，那么回滚的是自己的事务(自己是否有事务？)，如果自己有事务，那么父事务(registry)就不会受到影响，insertUser肯定也不会受到影响。
测试：
发送请求：
查看日志：
查看数据库：
我们可以看到，insertLog进行了回滚，而insertUser插入成功了
结论：insertLog在进行事务回滚的时候，把自己的事务进行了回滚，则父事务(registry)和insertUser就不受影响，若insertLog不回滚自己的事务，当自己发生异常，一定会影响到父事务(registry)，insertUser它也是依靠于父事务的，所以也会受到影响。
我们知道使用required，若出现异常则全部回滚，那么把异常按照上述的一个处理方式是否会全部回滚？
调用方代码：
被调用方代码：
发送请求：
查看日志：
发现没有任何提交，全部回滚！
NESTED和REQUIRED区别：
- 整个事务如果全部执⾏成功,⼆者的结果是⼀样的
- 如果事务⼀部分执⾏成功,REQUIRED加⼊事务会导致整个事务全部回滚.NESTED嵌套事务可以实 现局部回滚,不会影响上⼀个⽅法中执⾏的结果
嵌套事务之所以能够实现部分事务的回滚,是因为事务中有⼀个保存点(savepoint)的概念,嵌套事务 进⼊之后相当于新建了⼀个保存点,⽽滚回时只回滚到当前保存点
REQUIRED是加⼊到当前事务中,并没有创建事务的保存点,因此出现了回滚就是整个事务回滚,这就 是嵌套事务和加⼊事务的区别 总结：
- 1 Spring中使⽤事务,有两种⽅式:编程式事务(⼿动操作)和声明式事务.其中声明式事务使⽤较多,在⽅法上添加 @Transactional 就可以实现了
- 2 通过@Transactional(isolation = Isolation.SERIALIZABLE)设置事务的隔离级 别.Spring中的事务隔离级别有5种
- 3 通过@Transactional(propagation =Propagation.REQUIRED)设置事务的传播机制,Spring中的事务传播级别有7种,重点关注REQUIRED(默认值)和REQUIRES_NEW