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

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

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

            1、什么是spring事务。

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

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

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

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

一、什么是spring事务

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

事务四大特性：

事务隔离级别：

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

事务传播机制：

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

总结：

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

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

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

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

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

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

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

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

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

1：注解方式（本章不重点讲解）

当不开启事务时：

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

测试前数据表：

调用测试接口：

测试后数据表：

结果：

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

当开启事务时：

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

测试前数据表：

调用测试接口:

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

测试后数据表:

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

2：xml方式

当不开启事务时：

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

当开启事务时：

开启方式：******************

先创建transaction.xml文件，如下：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
     xmlns:tx="http://www.springframework.org/schema/tx"
     xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/tx
        http://www.springframework.org/schema/tx/spring-tx.xsd
        http://www.springframework.org/schema/aop
        http://www.springframework.org/schema/aop/spring-aop.xsd">
 
  <!--  定义事务管理对象  -->
  <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource" ></property>
  </bean>
 
  <!--  配置事务处理  -->
  <tx:advice id="txAdvice" transaction-manager="txManager">
    <tx:attributes>
      <tx:method name="*" read-only="true" timeout="7200" />
      <tx:method name="get*" rollback-for="Exception" read-only="true" ></tx:method>
      <tx:method name="add*" ></tx:method>
      <tx:method name="delete*" rollback-for="Exception" read-only="true" ></tx:method>
      <tx:method name="update*" rollback-for="Exception" read-only="true" ></tx:method>
    </tx:attributes>
  </tx:advice>
 
  <!--  配置aop的切点和切点的处理  -->
  <aop:config>
    <aop:pointcut id="allManagerMethod" expression="execution (* com.swagger.demo.service.UserService.*(..))" />
    <aop:advisor advice-ref="txAdvice" pointcut-ref="allManagerMethod" order="0"/>
  </aop:config>
 
</beans>

代码解读如下：

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

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

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

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默认的隔离级别） 。

       下面开始通过两个接口来测试事务隔离级别读未提交（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操作的耗时才算超时时间，方法内的业务代码超时时间是不算的（记住这个小坑）。