• 【二十三】springboot整合spring事务详解以及实战


            一直对spring事务这一块内容处于极度浅显的面试理论阶段,实际上并没有仔细学习总结过,这次花了点时间对spring事务进行了一些学习并将自己的学习笔记总结在此处,下面开整。首先从spring事务的概念到代码使用上进行我自己的一番理解解读。

            将从下面几点开始一步一步开始学习:

                 1、什么是spring事务

                 2、为什么新建的springboot项目有时候自带事务处理,有时候不带事务处理

                 3、spring事务到底如何使用以及使用方式有几种

                 4、spring事务的多个属性的操作演练

            本章demo使用前面springboot整合swagger篇demo进行改造的,代码会上传git。

    目录

    一、什么是spring事务

    二、为什么新建的springboot项目有时候自带事务处理,有时候不带事务处理

    三、spring事务到底如何使用以及使用方式有几种

    四、spring事务的多个属性的实际操作演练

    1、事务是否只有可读权限(read-only)

    2、事务发生指定的异常后回滚(rollback-for)

    3、事务发生指定的异常后不回滚(no-rollback-for)

    4、事务隔离级别(isolation)

    5、事务传播性(propagation)

    6、事务超时时间(timeout)


    一、什么是spring事务

            spring事务类似与mysql的事务差不多,也是mysql事务的那些特性以及功能。

    事务四大特性:

    名称描述
    一致性事务执行前后数据的完整性必须保持一致。
    原子性事务是一个不可分割的单位,里面的内容要么都执行,要么都不执行
    隔离性多个用户并发访问数据库时,多个用户的事务互不影响,多个并发事务的数据应该是相互隔离的。
    持久性已被提交的事务对数据库的修改应该永久保存在数据库中

    事务隔离级别:

            下面第二节表格描述了,这里就不重复了。

    事务传播机制:

            下面第二节表格也描述了,这里就不重复了,要看就楼下去看。

    总结:

            spring事务大概就是这些点。最常用的使用他的目的就是他的四大特性,我认为最主要的就是原子性,保持方法内的数据库操作要么全部成功,要么全部失败。

            /下面针对有些时候为什么我感觉事务处理好像项目已经自带了,有时候又感觉没有事务处理的问题进行了学习/


    二、为什么新建的springboot项目有时候自带事务处理,有时候不带事务处理

            针对这个问题,需要去项目中找spring容器中是否注册了这样一个类DataSourceTransactionManager,若存在则可以使用使用事务,若不存在则需要去引入带有这个类的依赖jar包,类似mybatis以及spring-jdbc依赖下面都有这个类。

            找到这个类后,说明你的项目是支持事务处理的,只是开没开起或者事务失效不失效的问题了,下面介绍两种开启事务的方式。本文章重点讲解xml+aop形式(方便全局处理)。


    三、spring事务到底如何使用以及使用方式有几种

            上面说到当项目中有 DataSourceTransactionManager类存在时,可以使用事务,开启事务有两种方式,如下:

    开启方式具体操作
    注解方式

    1、在启动类加注解@EnableTransactionManagement开启事务处理功能。

    2、在具体需要事务处理的方法上加注解@Transactional,进行事务处理。

    xml方式

    1、新建xml文件,新建bean、tx、aop标签,配置需要事务处理的地方。

    2、在启动类通过@ImportResource注解导入该资源@ImportResource("classpath:transaction.xml")

            以上两种方式使用其一即可。

    下面针对两种方式进行演示:

    1:注解方式(本章不重点讲解)

    当不开启事务时:

    如上代码可以看到执行mybatis-plus的保存语句后,会报错,并没有手动处理异常,此种情况,会保存成功吗?答案是会,因为没有做事务处理,测试如下:

    测试前数据表:

    调用测试接口:

    测试后数据表:

    结果:

    虽然报错了,但是仍然保存了数据,没有自动做事务处理。 

    当开启事务时:

    通过注解方式开启了事务处理,下面在进行测试。

    测试前数据表:

    调用测试接口:

    接口仍然在代码计算分母为0处报错了。

    测试后数据表:

    数据表数据没有新增,说明数据在报错后回滚了,说明进行了事务处理,事务处理开启成功。但是这种方式有个很大的麻烦点,你需要到所有需要事务处理的方法上去加@Transactional注解,有点相当的麻烦,所想统一处理呢,怎么操作?可以通过xml+aop的方式实现,下面开始本章的重点学习对象,就是xml方式实现spring事务处理。

    2:xml方式

    当不开启事务时:

    将上面测试时添加的两个注解都删了,然后测试接口的事务处理。上面已经测试过了,这里就不写了。

    当开启事务时:

    开启方式:******************

    先创建transaction.xml文件,如下:

    1. <?xml version="1.0" encoding="UTF-8"?>
    2. <beans xmlns="http://www.springframework.org/schema/beans"
    3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
    4. xmlns:tx="http://www.springframework.org/schema/tx"
    5. xsi:schemaLocation="
    6. http://www.springframework.org/schema/beans
    7. http://www.springframework.org/schema/beans/spring-beans.xsd
    8. http://www.springframework.org/schema/tx
    9. http://www.springframework.org/schema/tx/spring-tx.xsd
    10. http://www.springframework.org/schema/aop
    11. http://www.springframework.org/schema/aop/spring-aop.xsd">
    12. <!-- 定义事务管理对象 -->
    13. <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    14. <property name="dataSource" ref="dataSource" ></property>
    15. </bean>
    16. <!-- 配置事务处理 -->
    17. <tx:advice id="txAdvice" transaction-manager="txManager">
    18. <tx:attributes>
    19. <tx:method name="*" read-only="true" timeout="7200" />
    20. <tx:method name="get*" rollback-for="Exception" read-only="true" ></tx:method>
    21. <tx:method name="add*" ></tx:method>
    22. <tx:method name="delete*" rollback-for="Exception" read-only="true" ></tx:method>
    23. <tx:method name="update*" rollback-for="Exception" read-only="true" ></tx:method>
    24. </tx:attributes>
    25. </tx:advice>
    26. <!-- 配置aop的切点和切点的处理 -->
    27. <aop:config>
    28. <aop:pointcut id="allManagerMethod" expression="execution (* com.swagger.demo.service.UserService.*(..))" />
    29. <aop:advisor advice-ref="txAdvice" pointcut-ref="allManagerMethod" order="0"/>
    30. </aop:config>
    31. </beans>

    代码解读如下: 

    1:此处是定义事务管理对象,就是上面提到的那个类,此处截图爆红是因为还没有在springboot项目的启动类导入该配置文件。

    2:通过aop定义切点,切到需要处理事务的地方,里面的匹配方式就是aop切点的匹配规则,百度吧,东西不多,此处不展开。 

    3:创建tx标签,关联aop对象和事务管理对象,配置需要事务处理的地方。下面解释tx标签的属性。

    属性名描述

    name

    事务处理的方法名称,可以通过*号进行模糊匹配方法名称,处理的方法是aop切点切到的位置。没有默认值

    read-only

    事务对数据库是否只有只读权限,true,false,默认是false

    rollback-for

    发生指定的异常后回滚,多个时逗号隔开,默认值是runtimeException

    isolation

    事务隔离级别。

    1:default:由数据库自动判断应使用什么隔离级别。默认是default

    2:read_uncommitted:可以读取未提交的数据。可能出现脏读、不重复读、幻读。效率最高。
    3:read_committed:只能读取其他事务已经提交的数据。可以防止脏读,可能出现不重复读、幻读。

    4:repeatable_read:读取的数据被添加锁,防止其他事务修改此数据。可以防止脏读、不重复读,可能出现幻读。
    5:serializable:排队操作,对整个表加锁。一个事务在操作数据时,另一个事务必须等待事务操作完成后才能操作这个表。

    no-rollback-for

    发生指定的异常不会回滚,多个时逗号隔开,没有默认值

    propagation

    事务传播性。

    1:REQUIRED:支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择。(默认REQUIRED)

    2:SUPPORTS:支持当前事务,如果当前没有事务,就以非事务方式执行。

    3:MANDATORY:支持当前事务,如果当前没有事务,就抛出异常。

    4:REQUIRES_NEW:新建事务,如果当前存在事务,把当前事务挂起。

    5:NOT_SUPPORTED:以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。

    6:NEVER:以非事务方式执行,如果当前存在事务,则抛出异常。

    7:NESTED:支持当前事务,如果当前事务存在,则执行一个嵌套事务,如果当前没有事务,就新建一个事务。

    timeout

    事务超时,就是指一个事务所允许执行的最长时间,如果超过该时间限制但事务还没有完成,则自动回滚事务,没有默认的超时时间。

    ps:创建好xml文件后,其次记得要引入aop的jar包,不然启动报错,因为xml文件使用了aop的标签。

     

    最后,启动类导入该文件,@ImportResource("classpath:transaction.xml")

    这个东西注意了,必须加上,否则事务配置的xml文件不会生效,一定记得加哦!!!

    创建好xml文件并导入后,我们继续测试add方法,并采用所有的默认spring事务配置进行测试(后面小节进行其他属性的一一测试)。  

    测试前数据表:

    调用接口:

    测试后数据表:

    数据表没有新增数据,说明采用标签的默认的事务处理是生效了的。后面小节针对上面表格的6个属性值(read-only,rollback-for,isolation,no-rollback-for,propagation,timeout)进行学习。


    四、spring事务的多个属性的实际操作演练

    1、事务是否只有可读权限(read-only)

            针对这个属性的学习还是拿上面的add方法进行测试。

    false时:

    默认是false,所以当不写时就是false,测试上面add方法是否会新增成功呢?答案是:肯定会

    true时:

            上面这种情况时呢,会发生什么?

            可以发现接口报了sql异常了,连接只可以读,数据库数据也没有新增,确实进行了事务处理

            接下来再试试另一个参数rollback-for的学习,指定异常回滚


    2、事务发生指定的异常后回滚(rollback-for

            由于Spring事务的回滚会自动回滚发生的runtimeException异常,所以本小结的学习自定义一个自己的异常类型——MyException

            然后改造add方法。如下:

            手动捕获这个runtimeException异常,然后由我们自己手动抛一个自定义的异常出去,再不修改 rollback-for属性的情况下,调用接口,事务会回滚吗?答案是不会,因为我自定义的异常继承自Exception,而不是运行时异常,测试看看,调用接口前数据库表是这样的:

    调用接口后:

            虽然报错了,但是数据库数据仍然新增成功了,并没有回滚,没有事务处理

            下面试试rollback-for属性的作用。

            再进行测试。

    测试前数据表:

    调用接口后:

     

            数据显然没有新增成功,所以事务回滚了,进行了事务处理,rollback-for的作用体现出来了,若需要让事务处理多个自定义异常的话,用逗号隔开即可,如:<tx:method name="add*" rollback-for="MyException,MyException2,MyException3" ></tx:method>。

    补充:关于异常回滚这块,需要注意一个东西:try-catch手动捕获异常,即使是runtimeException类型的异常,若手动捕获了异常并没有再抛出runtimeException异常(要把异常抛出去,抛到方法外让别人能发现,不能自己抓起来),就不会进行事务处理了就是所谓的事务失效

            意思就是如下情况:

    手动捕获,但是抛出了运行时异常能回滚

    手动捕获,但是未做其他处理不能回滚

    直接抛出运行时异常类ArithmeticException,继承至运行时异常类,能回滚

            言归正传,下面学习no-rollback-for属性,设置指定异常不回滚


    3、事务发生指定的异常后不回滚(no-rollback-for

            上面有说到运行时异常都会进行事务处理,demo中的ArithmeticException异常就是runtimeException,若现在我需要设置即使发生这个异常也不回滚,怎么做呢?下面就可以通过这个属性实现。

            上面已经测试过发生这个异常会回滚,所有这里直接测试将这个属性设置到no-rollback-for属性,测试是不是不会回滚?

    测试前数据库表:

    调用接口:

            虽然报错了,但是仍然插入了数据,说明的确在设置no-rollback-for属性值为ArithmeticException时,Spring事务不回滚了,前面的提出的假设需求就回答了,这就是no-rollback-for属性的作用。同样的,若需要处理多个异常不进行事务处理,就用逗号隔开即可。


    4、事务隔离级别(isolation

            事务隔离级别一直都是懵懵懂懂的概念,这次浅学一下。

            isolation属性就是设置事务隔离级别的,默认是default(由数据库自动判断应使用什么隔离级别)。

            这一小节就测试一下read_uncommitted(可以读取未提交的数据。可能出现脏读、不重复读、幻读。效率最高)。

            首先先查看下自己的mysql是使用的什么隔离级别

    mysql版本查看隔离级别方式
    8.0以上

    select @@transaction_isolation 

    8.0以下

    select @@tx_isolation

            这是我的(可重复度,即mysql默认的隔离级别) 。

            下面开始通过两个接口来测试事务隔离级别读未提交(read_uncommitted)。

            现在模拟一种情况张三在新增一个用户"马冬梅",但是事务还没有执行完,还没有提交到数据库,这个时候李四上去查询用户,如果是default情况下,李四是肯定查询不到"马冬梅"的,为default时,我已经测试过了,查询不到,但是我现在抽风了,我就是要查询到这个"马冬梅",怎么办?就可以设置事务隔离级别为读未提交,下面开始整这个demo。

            1、还原add方法,并新增一个get方法用于查询所有用户。 

           2、改造xml文件,设置这两个方法的事务隔离级别

            3、运行这个项目,跑两个端口,一个给张三用于新增,一个给李四用于查询

     

            先看看现在表的情况。

            有这样5条数据。

            张三现在用8085端口新增马冬梅(在add方法加个断点,防止数据立刻提交),李四用8086查询

            张三新增马冬梅,断点不放开。

            可以看到数据库表数据未新增,因为事务还没有提交嘛。现在让李四到8086端口查询。

            可以看到,李四查询出了张三还未提交事务到数据库的数据"马冬梅"。

            后面的其他隔离级别这里就不写了,太多了。 


    5、事务传播性(propagation

            除了事务隔离级别,还有个事务传播机制也经常被面试官问到,趁现在也大概学习一下。

            本小结通过设置REQUIRED(支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择,也是最简单的处理)进行学习。默认的传播机制是也是REQUIRED。通过学习,我认为事务传播性基本上就是发生在多个方法上,比如A方法有事务,A方法内调用B方法,而B方法也有事务,或者A方法没有事务时,事务它到底如何处理,这就是事务传播机制

            我先用语言描述一下我对于默认的REQUIRED的了解。

            假设如果有一个A方法需要新增用户的基本信息,而B方法需要新增他的父亲和母亲的基本信息,则在A方法新增完自己的信息后调用B方法。若两个方法都存在事务时,则B方法的事务就不会创建,而是和A方法公用一个事务,意思就是出异常了就一起回滚;而若方法不存在事务,B方法存在事务,就会新建一个B方法自己的事务,A方法出异常也不会回滚,而B方法会回滚

            下面通过代码实现。

            新建一个service和实现类存放新增父母信息的方法(原因:放在同一个类下会发生事务失效的问题,我试了很久,你也可以试一下,要放在不同类下),如下:

    1、新增addFather方法

    2、改造原来的add方法

    3、新增addFather方法的事务处理

    测试前数据表数据:

    调用接口测试:

     

     

            发现数据库没有新增数据,两个方法的事务都回滚了,说明第二个事务在发现当前存在事务时,直接加入了第一个事务,只存在同一个事务。

            下面测试若只有B存在事务,A不存在事务时,是不是B会新建事务,效果预测将会是马冬梅新增成功,而他的父母不会新增成功。

    测试操作如下:

    1、关闭add方法的事务,只开启addFather方法的事务

    测试前数据表:

    调用接口:

            结果:发生了运行时异常,并回滚了B方法的事务,但是没有回滚A方法的事务,说明B方法在当前不存在事务的情况下,新建了一个自己的事务。


    6、事务超时时间(timeout

            对于事务超时时间的学习,下面继续通过add方法的demo进行学习。

    注意:这里的超时时间是数据库连接的超时时间,而不是整个方法的超时时间,若有兴趣可以试试方法内线程睡眠,可以看到事务不会回滚,我已经试过了,哈哈。

            改造add方法,由于每次插入方法太短,直接给他来个循环10000次。

    测试前:

    调用接口后:

            成功触发超时事务。学习时一直测试不出这个超时时间的效果,总感觉没作用,直接给他上个1毫秒就算超时,就给我回滚,终于出效果了。记住:只有数据库连接上以后的jdbc操作的耗时才算超时时间,方法内的业务代码超时时间是不算的(记住这个小坑)。

  • 相关阅读:
    vue中 router.beforeEach() 的用法
    [项目管理-8]:软硬件项目管理 - 项目成本管理(钱、财)
    产品开发和制造中,FMEA不起作用的原因及改善方法——FMEA软件
    学习Autodock分子对接
    xtrabackup 2.4 的介绍与使用
    SpringBoot打造企业级进销存 第二讲 (一)
    C++项目——集群聊天服务器项目(六)MySQL模块
    设了止损就万事大吉了?白银漫谈(一)
    网络攻防原理与技术 第一章 课后题
    Python学习笔记(一)
  • 原文地址:https://blog.csdn.net/weixin_56995925/article/details/125577851