⭐️前言⭐️
事务是作为一名后端程序员,必须去要了解清楚的东西,因为它决定了程序的正常运行以及与程序运行效率之间的权衡,这篇文章我们就来了解一下Spring事务和事务传播机制。
🍉欢迎点赞 👍 收藏 ⭐留言评论 📝私信必回哟😁
🍉博主将持续更新学习记录收获,友友们有任何问题可以在评论区留言
🍉博客中涉及源码及博主日常练习代码均已上传至GitHub
📍内容导读📍
- 🍅1.为什么需要事务?
- 🍅2.Spring中事务的实现
- 2.1 MySQL中的事务使用(回顾)
- 2.2 Spring 编程式事务(了解即可,很少用)
- 2.3 Spring 声明式事务(自动)
- 2.4 Spring 声明式事务手动回滚
- 2.5 @Transactional 工作原理
- 🍅3.事务隔离级别
- 3.1 事务特性回顾
- 3.2 Spring中设置事务隔离级别
- 3.2.1 MySQL 4种事务隔离级别
- 3.2.2 Spring 5种事务隔离级别
- 🍅4.事务传播机制
- 4.1 为什么需要事务传播机制?
- 4.2 事务传播机制有哪些?
- 4.3 Spring事务传播机制使用和场景演示
- 4.3.1 支持当前事务(REQUIRED)
- 4.3.2 嵌套事务(NESTED)
- 4.3.3 嵌套事务(NESTED)和加入事务(REQUIRED )的区别
🍅1.为什么需要事务?
事务的定义
将一组操作封装成一个执行单元,要么全部成功,要么全部失败。
为什么要用事务?
比如转账操作分为两个步骤:
第一步操作:A账户-100元
第二步操作:B账户+100元
如果没有事务,第一步执行成功了,第二步失败了,那么A账户平白无故的100元就“人间蒸发”了。而如果使用事务就可以解决这个问题,让这一组操作要么一起成功,要么一起失败。
🍅2.Spring中事务的实现
Spring中的事务操作分为两类:
1.编程式事务(手动写代码操作事务,在实际开发中几步用不到)
2.声明式事务(利用注解自动开启和提交事务)
在讲解Spring中的事务之前,我们先来回顾事务在MySQL中是如何使用的?
2.1 MySQL中的事务使用(回顾)
事务在MySQL中有3个重要的操作:开启事务、提交事务、回滚事务,它们对应的操作命令如下:
-- 开启事务
start transaction;
-- 业务执行-- 提交事务
commit;-- 回滚事务
rollback;
2.2 Spring 编程式事务(了解即可,很少用)
Spring手动操作事务和上面MySQL操作事务类似,它也是有3个重要操作步骤:
- 开启事务(获取事务)
- 提交事务
- 回滚事务
SpringBoot内置了两个对象,DataSourceTransactionManager
用来获取事务(开启事务)、提交或回滚事务的,而TransactionDefinition
是事务的属性,在获取事务的时候需要将TransactionDefinition
传递进去从而获得一个事务TransactionStatus
,实现代码如下:
这种方法虽然可以实现,但是很繁琐,在实际开发中几乎不会用到,更多的是用下边这种声明式事务的方法。
2.3 Spring 声明式事务(自动)
声明式事务的实现很简单,只需要在需要的方法上添加@Transactional
注解就可以实现了,无需手动开启事务和提交事务,进入方法时自动开启事务,方法执行完会自动提交事务,如果中途发生了没有处理的异常会自动回滚事务,具体实现代码如下:
@Transactional可以用来修饰方法或类:
- 修饰方法时:需要注意只能应用到public方法上,否则不生效。
- 修饰类时:表明该注解对该类中所有的public方法都生效
@Transactional参数说明
2.4 Spring 声明式事务手动回滚
@Transactional在异常被捕获的情况下,不会进行事务自动回滚,如下代码所示:
为了解决上述事务不会自动回滚的问题,有以下两种解决方法:
方案一:将异常继续抛出去【声明式事务会自动回滚】
方案二:通过代码手动回滚事务
2.5 @Transactional 工作原理
@Transactional
是基于AOP实现的,AOP又是使用动态代理实现的。如果目标对象实现了接口,默认情况下会采用JDK Proxy
的动态代理,如果目标对象没有实现接口,会使用CGLIB
动态代理。
@Transactional
在开始执行业务之前,通过代理先开启事务,在执行成功之后再提交事务。如果中途遇到异常,则回滚事务。
@Transactional
实现思路预览:
@Transactional
具体执行细节如下图所示:
🍅3.事务隔离级别
3.1 事务特性回顾
事务有4大特性(ACID),原子性、持久性、一致性和隔离性,具体概念如下:
- 原子性:一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
- 一致性:在事务开始之前和事务结束之后,数据库的完整性没有被破坏。这表示写入的数据必须完全合理,这包含数据的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- 持久性:事务处理结束后,对数据的修改是永久的(写入硬盘的),不会因为程序/主机的重启而丢失
- 隔离性:数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交、读已提交、可重复读和串行化。
3.2 Spring中设置事务隔离级别
3.2.1 MySQL 4种事务隔离级别
下述表格中x代表可能存在的问题,√代表能够解决的问题。
隔离级别 | 分析 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|---|
读未提交(Read Uncommitted) | 允许读未提交的数据,并发程度最高,隔离性最低 | × | × | × |
读已提交(Read Committed) | 只能读提交以后的数据(相当于写加锁),并发程度降低,隔离性提高 | √ | × | × |
可重复读(Repeatable Read) | 相当于读和写都加锁了,并发程度再降低,隔离性再提高 | √ | √ | × |
串行化(Serializable) | 严格执行串行化,并发程度最低,隔离性最高 | √ | √ | √ |
- 脏读:一个事务读取到了另一个事务修改的数据之后,后一个事务又进行了回滚操作,从而导致第一个事务读取的数据是错误的。
- 不可重复度:一个事务两次查询到的结果不同,因为在两次查询中,有另一个事务把数据修改了。
- 幻读:一个事务两次查询到的结果不同,因为在两次查询中,有另一个事务又新增了一部分数据。
3.2.2 Spring 5种事务隔离级别
Spring中事务隔离级别可以通过@Transactional
中的isolation
属性进行设置,具体操作如下图所示:
即包含以下5种隔离级别:
1.Isolation.DEFAULT:以连接的数据库的事务隔离级别为主。
2.Isolation.READ_UNCOMMITTED:读未提交,可以读取到未提交的事务,存在脏读。
3.Isolation.READ_COMMITTED:读已提交,只能读取到已经提交的事务,解决了脏读,存在不可重复读。
4.Isolation.REPEATABLE_READ:可重复读,解决了不可重复读,但存在幻读(MySQL默认级别)
5.Isolation.SERIALIZABLE:串行化,可以解决所有并发问题,但性能太低。
从上述介绍可以看出,相比于MySQL的事务隔离级别,Spring的事务隔离级别只是多了一个Isolation.DEFAULT(以数据库的全局事务隔离级别为主)
🍅4.事务传播机制
4.1 为什么需要事务传播机制?
事务隔离级别是保证多个并发事务执行的可控性的(稳定性的),而事务传播机制是保证一个事务在多个调用方法间的可控性的(稳定性的)。
事务隔离级别解决的是多个事务同时调用一个数据库的问题,如下图所示:
而事务传播机制解决的是一个事务在多个节点(方法)中传递的问题,如下图所示:
4.2 事务传播机制有哪些?
Spring事务传播机制包含以下7种:
1.Propagation.REQUIRED:默认的事务传播级别,它表示如果当前存在事务,则加入该事务;如果当前没有事务,则创建一个新的事务。
2.Propagation.SUPPORTS:如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务的方式继续运行。
3.Propagation.MANDATORY:(mandatory:强制性)如果当前存在事务,则加入该事务;如果当前没有事务,则抛出异常。
4.Propagation.REQUIRES_NEW:表示创建一个新的事务,如果当前存在事务,则把当前事务挂起。也就是说不管外部方法是否开启事务,Propagation.REQUIRES_NEW修饰的内部方法会新开启自己的事务,且开启的事务相互独立,互不干扰。
5.Propagation.NOT_SUPPORTED:以非事务方式运行,如果当前存在事务,则把当前事务挂起。
6.Propagation.NEVER:以非事务方式运行,如果当前存在事务,则抛出异常。
7.Propagation.NESTED:如果当前存在事务,则创建一个事务作为当前事务的嵌套事务来运行;如果当前没有事务,则该取值等价于Propagation.REQUIRED。
以上7种传播行为,可以根据是否支持当前事务分为以下3类:
以情侣买房的问题为例来理解以上分类:
4.3 Spring事务传播机制使用和场景演示
4.3.1 支持当前事务(REQUIRED)
UserController 实现代码:
UserService实现代码:
可以发现service
类中的两个方法的事务传播级别都是REQUIRED
。
第一个方法没有异常,如果调用该方法,数据库中应该正常插入一条记录,但是第二个方法有异常,就会导致整体回滚,数据库中不会插入记录,验证结果如下:
该事务传播级别的执行流程,就是任意一个该级别的方法出现异常,整个方法调用链会进行整体回滚。
4.3.2 嵌套事务(NESTED)
验证该级别的UserController
类中代码与验证REQUIRED
级别的类中代码相同,UserService
类中代码就只是改了第二个方法的事务传播级别,如下所示:
更改代码后进行方法调用,可以发现,数据库中插入了一条记录,说明第一个方法正常执行了,只有第二个方法进行了回滚,验证结果如下:
该事务传播级别的执行流程,就是如果该级别的方法出现了异常,只回滚该方法,不影响整体。
4.3.3 嵌套事务(NESTED)和加入事务(REQUIRED )的区别
- 整个事务如果全部执行成功,二者的结果是一样的
- 如果事务执行到一半失败了,那么加入事务的整个事务全部回滚;而嵌套事务会局部回滚,不会影响上一个方法中执行的结果。
⭐️最后的话⭐️
总结不易,希望uu们不要吝啬你们的👍哟(^U^)ノ~YO!!如有问题,欢迎评论区批评指正😁