由工作问题到Mybatis缓存与Spring事务管理

本文主要是介绍由工作问题到Mybatis缓存与Spring事务管理，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

 太长不看 人士直接到  结论分析；

问题背景：

　　　　项目使用SpringBoot+SpringMVC+Mybatis框架

　　　　工作中遇到一个工作流向外同步的问题，在本地工作流操作完之后，调用接口推动其他平台的工作流流转。

　　在本地工作流操作完之后，数据库中业务数据对应的工作流状态会发生变化，比如auditStatus从0转为1等。

主要现象：

　　　　工作流的本地操作调用系统的公用接口，在本地工作流操作完之后（已经更改了数据的流程状态），调用dao层根据id去数据库检索该条业务数据。

　　这时候意料之外的情况出现了，检索出的数据中流程状态仍是工作流未操作之前的。

问题分析：

　　　　像这种情况，首先想到的就是Spring的事务,具体点就是事务的传播机制（propagation）和数据隔离级别（ioslation）。代码结构如下

　　　　　　@Override
　　　　　　@Transactional(propagation = Propagation.REQUIRED)
　　　　　　public void executeSth(Student student) {

　　　　　　　　Student origin = studentServiceStrong.getById(student.getId());
　　　　　　　　System.out.println("before update:"+origin);
　　　　　　　　ShitHandler handler = new ShitHandler();
　　　　　　　　int i = handler.updateSomeShitByIdWithNewBean(student);
　　　　　　　　Student dbRec = studentServiceStrong.getById(student.getId());

　　　　　　}

　　　　　生产环境中的代码是使用的全局事务配置，没有直接加注解，我在这里为了直观写上了等价的注解，

　　　　　handler.updateSomeShitByIdWithNewBean(student);这一句的内部操作事务的Propagation为REQUIRES_NEW.

　　　　　现场库使用的是mysql。下来分析的时候，ioslation走的innodb默认的repeatable read,按理不会出现这种情况，因为外层事务读取的时候内层事务已经提交了。
　　　　　在深入update方法内部看，原来在这个公共接口中，在新事务创建之前，有对该条数据根据id进行检索，此次检索与更新完之后的检索在同一事务中，根据repeatable read的特点，

　　　　    两次检索的结果一样，即没有检索到更新，是解释的通的。所以这里先将ioslation设置为read committed，理论上就可以让后一次select检索到数据了。

　　　　　但是，可怕的但是，系统支持多数据源，在本地用oracle库进行测试时，也出现了同样的问题，oracle默认隔离级别为read committed，按理说最后一次检索应该能检索到更新。

　　　　　所以我们发现，并不是ioslation的问题，起码不全是ioslation的问题。还有什么可能呢，mybatis缓存。

结论分析：

　　　　在以上代码中，mysql中的同一事务的两次检索结果不一致，最直接的原因并不是repeatable read的特性导致，因为这里其实后一次并未真正落到数据库（oracle也是）---日志并没有对应的sql输出，而是读了Mybatis的一级缓存。
　　　　当我们将缓存禁用后，这时在mysql中的不一致才是repeatable read特性导致的（此时在oracle已经正常）。

　　　　Mybatis一级缓存默认开启，在开启时，同一次会话（session）中的第一次检索的对应数据会进行缓存，缓存对应的规则可以参考这篇文章： https://www.cnblogs.com/happyflyingpig/p/7739749.html
　　　　众所周知，一级缓存在数据被update时会被对应的移除，但是，实践显示，有一个非常重要的前提：select和之前update在同一事务中，如果在不同的事务中，mybatis不会失效对应的缓存　　　　

 　　　　关闭Mybatis一级缓存：

　　　　　　全局关闭：

　　　　　　　　mybatis.configuration.local-cache-scope=statement
　　　　　　某一次检索关闭：

　　　　　　　　在对应的statement中添加  flushCache="true"

　　　　加个题外话，很多人说new 出来的对象中的事务spring不能控制，其实这样说是不全面的，这里挖个坑，以后有时间了专门开一篇说。

解决方案:　　　　

　　　　因此，最后的解决方案为，在select的statement中加上 flushCache="true" ，且将几个相关方法的ioslation设置为read committed

 对应资源：

　　　　自己写的小demo，有兴趣可以跑跑看 　　https://gitee.com/uptotwo/ssm

这篇关于由工作问题到Mybatis缓存与Spring事务管理的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！