文章目录
前言
通过本篇学习,你将加深对 @Transactional 注解以及所有的属性的理解,还可以学习到 @Transactional 注解常见的失效场景。
@Transactional 注解特性如下:
- @Target({ElementType.TYPE, ElementType.METHOD}):设定注解使用范围是类和方法上;
- @Retention(RetentionPolicy.RUNTIME):设定生命周期为全周期,支持使用反射机制的代码读取和使用;
- @Inherited:指明如果该注解修饰的父类被子类继承,那么子类也具备事务特性;
- @Documented:表明这个注解应该被 javadoc工具记录。
一、参数详解
@Transactional 注解的关键属性大致有九个(如图):
参数 | 意义 |
---|---|
isolation | 事务隔离级别,默认为DEFAULT |
propagation | 事务传播机制,默认为REQUIRED |
readOnly | 事务读写性,默认为false |
noRollbackFor | 一组异常类,遇到时不回滚,默认为{} |
noRollbackForClassName | 一组异常类名,遇到时不回滚,默认为{} |
rollbackFor | 一组异常类,遇到时回滚,默认为{} |
rollbackForClassName | 一组异常类名,遇到时回滚,默认为{} |
timeout | 超时时间,以秒为单位 |
value | 可选的限定描述符,指定使用的事务管理器,默认为“” |
1.1、isolation(事务隔离级别)
隔离级别是指若干个并发的事务之间的隔离程度,与我们开发时候主要相关的场景包括:脏读取、重复读、幻读。
-
Isolation 的 Eum 类中定义了“五个”表示隔离级别的值,如下:
- Isolation.DEFAULT:使用各个数据库默认的隔离级别【默认】
- Isolation.READ_UNCOMMITTED:读取未提交数据(会出现脏读, 不可重复读)(基本不使用)
- Isolation.READ_COMMITTED:读取已提交数据(会出现不可重复读和幻读)
- Isolation.REPEATABLE_READ:可重复读(会出现幻读)
- Isolation.SERIALIZABLE:串行化
-
在这里,简单解释下什么是“脏读”,“不可重复读”,“幻读”:
- 脏读:一个事务读取到另一事务未提交的更新数据;
- 不可重复读: 在同一事务中,多次读取同一数据返回的结果有所不同。换句话说:后续读取可以读到另一事务已提交的更新数据。相反,"可重复读"在同一事务中多次读取数据时,能够保证所读数据一样,也就是后续读取不能读到另一事务已提交的更新数据;
- 幻读: 一个事务读到另一个事务已提交的 insert 数据;
-
最后,有必要补充一下常用数据库的默认隔离级别:
- MYSQL:默认为REPEATABLE_READ
- SQLSERVER:默认为READ_COMMITTED
- Oracle:默认隔离级别 READ_COMMITTED
注意:mysql数据库,当且仅当引擎是InnoDB,才支持事务(MyIsam引擎不支持事务)。
1.2、propagation(事务传播机制)
所谓事务的传播机制是指,如果在开始当前事务之前,一个事务上下文已经存在,此时有若干选项可以指定一个事务性方法的执行行为。
Propagation 的 Eum 类中定义了“七个”表示隔离级别的值,如下:
- Propagation.REQUIRED:如果当前没有事务,就新建一个事务,如果已经存在一个事务中,加入到这个事务中。这是 最常见的选择,也是Spring【默认】的传播机制
- Propagation.SUPPORTS:持当前事务,如果当前有事务,就以事务方式执行;如果当前没有事务,就以非事务方式执行
- Propagation.MANDATORY:使用当前的事务,且必须在一个已有的事务中执行,如果当前不存在事务,否则抛出异常
- Propagation.REQUIRES_NEW:不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务
- Propagation.NOT_SUPPORTED:以非事务方式执行,如果当前存在事务,就把当前事务挂起
- Propagation.NEVER:以非事务方式执行,且必须在一个没有的事务中执行,如果当前存在事务,则抛出异常【与Propagation.MANDATORY相反】
- Propagation.NESTED:如果当前存在事务,则在嵌套事务内执行;如果当前没有事务,则执行与【Propagation.REQUIRED 】类似的操作
1.3、readOnly(事务读写性)
默认情况下是 false(即:不指定只读性),设置为 true 的含义是: 告诉程序该方法下使用的是只读操作,如果进行其他非读操作,则会跑出异常。
- 事务的只读性,概念:
从这一点设置的时间点开始(时间点a),到这个事务结束的过程中,其他事务所提交的数据,该事务将看不见!!即:查询中不会出现别人在时间点a之后提交的数据。
-
应用场景:
-
如果你一次执行单条查询语句,则没有必要启用事务的只读性支持,数据库默认支持SQL执行期间的读一致性;
-
如果你一次执行多条查询语句,例如统计查询,报表查询。在这种场景下,多条查询SQL必须保证整体的读一致性,否则,在前条SQL查询之后,后条SQL查询之前,数据被其他用户改变,则该次整体的统计查询将会出现读数据不一致的状态。此时,就有必要启用事务的只读性支持。
-
【注意】:是一次执行多次查询来统计某些信息,这时为了保证数据整体的一致性,要用只读事务。
1.4、noRollbackFor 和 noRollbackForClassName(遇到时不回滚)
用来指明不回滚的条件是哪些异常类或者异常类名。
1.5、rollbackFor 和 rollbackForClassName(遇到时回滚)
用来指明回滚的条件是哪些异常类或者异常类名。
Spring默认情况下会对运行期异常(RunTimeException)进行事务回滚,如果遇到checked异常就不回滚。
1.6、timeout(超时时间)
用于设置事务处理的时间长度,阻止可能出现的长时间的阻塞系统或者占用系统资源,单位为秒。
如果超时设置事务回滚,并抛出TransactionTimedOutException异常。
1.7、value(指定使用的事务管理器)
value 主要用来指定不同的事务管理器,主要用来满足在同一个系统中,存在不同的事务管理器的场景需要。
比如,在Spring中声明了两种事务管理器txManager1,txManager2。然后,用户可以根据需要,修改这个参数来指定特定的txManager。
存在多个事务管理器的情况:在一个系统中,需要访问多个数据源,则必然会配置多个事务管理器。
二、@Transactional 注解的失效场景
@Transactional 注解的看似简单易用,但如果对它的用法一知半解,还是会踩到很多坑的。
我总结了六种常见的失效场景,概要如下,具体分析,请请看我另一篇博文:@Transactional 注解的失效场景,这个问题见过太多的人栽跟头,一篇刨根问底,让面试官都闭嘴
- @Transactional 应用在非 public 修饰的方法上,不支持回滚;
- @Transactional 注解属性 propagation 设置错误;
- @Transactional 注解属性 rollbackFor 设置错误;
- 在同一个类中方法调用,导致 @Transactional 失效;
- 异常被你的 catch 处理了,导致 @Transactional 没办法回滚而失效;
- 数据库配置了不支持事务的引擎,或者数据库本身就不支持事务。
三、@Transactional 注解源码
最后,附一张 @Transactional 注解的类源码图片,方便大家学习的时候做属性对照: