关于Spring事务及其传播机制
作者:快盘下载 人气:目录
一丶Spring中事务的实现<1>事务的四大特性有哪些<2>数据库并发一致性问题以及隔离级别的设置2>隔离可以解决的并发问题<3>Spring事务隔离级别<1>事务的传播机制是什么?为什么需要传播机制<2>事务的传播机制有哪些?<3>Spring事务传播机制使用和各种场景演示1>支持当前事务(REQUIRED)2>不支持当前事务(REQUIRES_NEW)3> 不支持当前事务,NEVER 抛异常4>NESTED 嵌套事务 + 嵌套事务和加入事务区别?这部分,就是关于事务了。emmmm,前言也不知道说啥了,人有点麻了。
还是老规矩,红色标题是重点。
一丶Spring中事务的实现
<1>mysql中的事务使用(回顾)
事务在MySQL 有 3 个重要的操作:开启事务、提交事务、回滚事务,它们对应的操作命令如下:
-- 开启事务 start transaction; -- 业务执行 -- 提交事务 commit; -- 回滚事务 rollback;
这样写可能有点空洞,那么我们按照实际来:
<2>手动操作事务
当前这种方式我们了解一下就行,我们主要使用是自动操作事务
Spring 手动操作事务和上面 MySQL 操作事务类似,它也是有 3 个重要操作步骤:
1.开启事务(获取事务)。
2.提交事务。
3.回滚事务。
SpringBoot 内置了两个对象, DataSourceTransactionManager 用来获取事务(开启事务)、提交或
回滚事务的,而 TransactionDefinition 是事务的属性,在获取事务的时候需要将TransactionDefinition 传递进去从而获得一个事务 TransactionStatus,实现代码如下:
<3>自动操作事务
声明式事务的实现很简单,只需要在需要的方法上添加 @Transactional 注解 就可以实现了,无需手动
开启事务和提交事务,进入方法时自动开启事务,方法执行完会自动提交事务,如果中途发生了没有处理的异常会自动回滚事务,具体实现代码如下:
此时我传值是true,所以这里会抛出一个异常
然后看一看我们的SQL数据库,也可以看到值没有修改
然后我们不让这个异常执行,也就是传一个false
可以看到此时修改成功
当然,除了这种做法,还有一种做法:配置一个声明式的AOP代理,拦截符合规则的方法,就可以自动的使用事务。
1>作用域说明
@Transactional 可以用来修饰方法或类: 修饰方法时:需要注意只能应用到 public 方法上,否则不生效。推荐此种用法。 修饰类时:表明该注解对该类中所有的 public 方法都生效。
但是!这里注意了,极其不推荐对类进行使用
2>参数说明
3>@Transactional 工作原理
@Transactional 是基于 AOP 实现的,AOP 又是使用动态代理实现的。如果目标对象实现了接口,默认情况下会采用 JDK 的动态代理,如果目标对象没有实现了接口,会使用 CGLIB 动态代理。
@Transactional 在开始执行业务之前,通过代理先开启事务,在执行成功之后再提交事务。如果中途遇
到的异常,则回滚事务。
@Transactional 实现思路预览:
@Transactional 具体执行细节如下图所示:
二丶事务隔离级别
<1>事务的四大特性有哪些
事务有4 大特性(ACID),原子性、持久性、一致性和隔离性,具体概念如下:
上面 4 个属性,可以简称为ACID。
原子性(Atomicity,或称不可分割性)
一致性(Consistency)
隔离性(Isolation,又称独立性)
持久性(Durability)。
而这 4 种特性中,只有隔离性(隔离级别)是可以设置的。
那为什么要设置事务的隔离级别呢?
设置事务的隔离级别是用来保障多个并发事务执行更可控,更符合操作者预期的。
什么是可控呢?
比如近几年比较严重的新冠病毒,我们会把直接接触到确证病例的人员隔离到酒店,而把间接接触者(和直接接触着但未确诊的人)隔离在自己的家中,也就是针对不同的人群,采取不同的隔离级别,这种隔离方式就和事务的隔离级别类似,都是采取某种行动让某个事件变的“更可控”。而事务的隔离级别就是为了防止,其他的事务影响当前事务执行的一种策略。
<2>数据库并发一致性问题以及隔离级别的设置
注意一下,我这里是部分解决,不是全部解决。
1>隔离级别的解读
2>隔离可以解决的并发问题
<3>Spring事务隔离级别
这个我们之后具体实践的时候再细细讲
但是这里不妨碍我们先体现提一下
三丶事务的传播机制
<1>事务的传播机制是什么?为什么需要传播机制
Spring 事务传播机制定义了多个包含了事务的方法,相互调用时,事务是如何在这些方法间进行传递
的。
事务隔离级别是保证多个并发事务执行的可控性的(稳定性的),而事务传播机制是保证一个事务在多
个调用方法间的可控性的(稳定性的)。
<2>事务的传播机制有哪些?
<3>Spring事务传播机制使用和各种场景演示
1>支持当前事务(REQUIRED)
这里可以看到我没有加注释,为什么呢?
因为REQUIRED是默认的隔离级别,如果也就是我们级别设置当中的
2>不支持当前事务(REQUIRES_NEW)
看我下面的代码演示,就是修改了一个权限级别
然后发起请求,重新访问
先看一下执行结果
可以发现其实没有修改成功,为什么呢?看我们的执行流程
然后学的时候,我觉得我自己在这里的问题描述不是很清楚,所以我重新描述一下问题就应该能理解清楚了
那么我们换种写法,把事务的开启挪一个地方
然后此时我们查看是否修改成功
这会又可以修改成功了,我们来看日志分析一下
3> 不支持当前事务,NEVER 抛异常
这个演示就很直接了,直接给你报错
4>NESTED 嵌套事务 + 嵌套事务和加入事务区别?
看我如下的代码演示,这个和上面的是有区别的熬,我这里两个方法同时给了嵌套注释,这是加入事务的演示
此时你可以看到,虽然说我都给了嵌套注释,但是这里其实和我上面的加入事务区别不是很大,为什么呢?往下走,继续往下看
此时数据库没有被修改,那么我们看看执行流程
是不是有点迷??没关系,我换种方式再演示一下,看看区别
这里我们设置回滚点
可以发现,很神奇的修改成功了
那么我们再来分析分析执行流程
现在是不是差不多看明白了?那么来语言总结一下
嵌套事务只所以能够实现部分事务的回滚,是因为事务中有一个保存点(savepoint)的概念,嵌套事务 进入之后相当于新建了一个保存点,而滚回时只回滚到当前保存点,因此之前的事务是不受影响的 而 REQUIRED 是加入到当前事务中,并没有创建事务的保存点,因此出现了回滚就是整个事务回滚,这 就是嵌套事务和加入事务的区别
所以
1.整个事务如果全部执行成功,二者的结果是一样的。
2.如果事务执行到一半失败了,那么加入事务整个事务会全部回滚;而嵌套事务会局部回滚,不会影
响上一个方法中执行的结果。
加载全部内容