【JavaEE进阶】 @Transactional详解

🍃前言

本篇博客的将讲述 @Transactional注解的使用细节

主要学习 @Transactional 注解当中的三个常见属性:

  1. rollbackFor:异常回滚属性.指定能够触发事务回滚的异常类型.可以指定多个异常类型

  2. Isolation:事务的隔离级别.默认值为 Isolation.DEFAULT

  3. propagation:事务的传播机制.默认为Propagation.REQUIRED

🌲rollbackFor(异常回滚属性)

@Transactional 默认只在遇到运行时异常和Error时才会回滚,非运行时异常不回滚.

即Exception的⼦类中,除了RuntimeException及其⼦类.

在这里插入图片描述

如果我们需要所有异常都回滚,需要来配置 @Transactional 注解当中的 rollbackFor 属性,通过 rollbackFor 这个属性指定出现何种异常类型时事务进行回滚

代码如下所示:

@Transactional(rollbackFor = Exception.class)

🎄事务隔离级别

我们先来看一下MySQL事务隔离级别都有那些

🚩MySQL事务隔离级别

SQL标准定义了四种隔离级别,MySQL全都⽀持.这四种隔离级别分别是:
在这里插入图片描述

  1. 读未提交(READUNCOMMITTED): 读未提交,也叫未提交读.该隔离级别的事务可以看到其他事务中未提交的数据.

因为其他事务未提交的数据可能会发⽣回滚,但是该隔离级别却可以读到,我们把该级别读到的数 据称之为脏数据,这个问题称之为脏读.

  1. 读提交(READ COMMITTED): 读已提交,也叫提交读.该隔离级别的事务能读取到已经提交事务的数据,

该隔离级别不会有脏读的问题.但由于在事务的执行中可以读取到其他事务提交的结果,所以在不同时间的相同 SQL
查询可能会得到不同的结果,这种现象叫做不可重复读

  1. 可重复读(REPEATABLE READ): 事务不会读到其他事务对已有数据的修改,即使其他事务已提交.也就可以确保同⼀事务多次查询的结果⼀致,但是其他事务新插⼊的数据,是可以感知到的.这也就引发了幻读问题.可重复读,是MySQL的默认事务隔离级别.

⽐如此级别的事务正在执⾏时,另⼀个事务成功的插⼊了某条数据,但因为它每次查询的结果都是⼀样的,所以会导致查询不到这条数据,自己重复插⼊时⼜失败(因为唯⼀约束的原因).明明在事务
中查询不到这条信息,但⾃⼰就是插⼊不进去,这个现象叫幻读.

  1. 串⾏化(SERIALIZABLE): 序列化,事务最⾼隔离级别.它会强制事务排序,使之不会发⽣冲突,从⽽解决了脏读,不可重复读和幻读问题,但因为执⾏效率低,所以真正使⽤的场景并不多

在数据库中通过以下SQL查询全局事务隔离级别和当前连接的事务隔离级别

select @@global.tx_isolation,@@tx_isolation;

🚩Spring事务隔离级别

Spring 中事务隔离级别有5 种:

  1. Isolation.DEFAULT :以连接的数据库的事务隔离级别为主.
  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)

🎋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 : 如果当前存在事务,则创建⼀个事务作为当前事务的嵌套事务来运⾏.如果当前没有事务,则该取值等价于PROPAGATION_REQUIRED .

可能上述理解起来有点儿抽象,这儿博主给大加举个例子吧

⽐如⼀对新⼈要结婚了,关于是否需要房⼦

  1. Propagation.REQUIRED :需要有房⼦.如果你有房,我们就⼀起住,如果你没房,我们就⼀起买房.(如果当前存在事务,则加⼊该事务.如果当前没有事务,则创建⼀个新的事务)
  2. Propagation.SUPPORTS : 可以有房⼦. 如果你有房,那就⼀起住.如果没房,那就租房.(如果当前存在事务,则加⼊该事务.如果当前没有事务,则以⾮事务的⽅式继续运⾏)
  3. Propagation.MANDATORY :必须有房⼦.要求必须有房,如果没房就不结婚.(如果当前存在事务,则加⼊该事务.如果当前没有事务,则抛出异常)
  4. Propagation.REQUIRES_NEW :必须买新房.不管你有没有房,必须要两个⼈⼀起买房.即使有房也不住.(创建⼀个新的事务.如果当前存在事务,则把当前事务挂起)
  5. Propagation.NOT_SUPPORTED :不需要房.不管你有没有房,我都不住,必须租房.(以非事务⽅式运⾏,如果当前存在事务,则把当前事务挂起)
  6. Propagation.NEVER :不能有房⼦.(以⾮事务⽅式运⾏,如果当前存在事务,则抛出异常)
  7. Propagation.NESTED :如果你没房,就⼀起买房.如果你有房,我们就以房⼦为根据地,做点小⽣意.(如果如果当前存在事务,则创建⼀个事务作为当前事务的嵌套事务来运⾏.如果当前没有事务,则该取值等价于PROPAGATION_REQUIRED )

这里我们需要注意一下NESTED和REQUIRED区别

  • 整个事务如果全部执⾏成功,⼆者的结果是⼀样的.
  • 如果事务⼀部分执⾏成功,REQUIRED加⼊事务会导致整个事务全部回滚.NESTED嵌套事务可以实现局部回滚,不会影响上⼀个方法中执⾏的结果.

嵌套事务之所以能够实现部分事务的回滚,是因为事务中有⼀个保存点(savepoint)的概念,嵌套事务进⼊之后相当于新建了⼀个保存点,而滚回时只回滚到当前保存点

使用方法与上述两个属性使用方法是一样的,进行相应属性值设置即可

@Transactional(propagation = Propagation.REQUIRED)

⭕总结

关于《【JavaEE进阶】 @Transactional详解》就讲解到这儿,感谢大家的支持,欢迎各位留言交流以及批评指正,如果文章对您有帮助或者觉得作者写的还不错可以点一下关注,点赞,收藏支持一下

评论 21
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

遇事问春风乄

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值