前言

上周五,一同事在开发时遇到了一个问题,叫我帮忙看下.在描述这个同事遇到问题之前,我先简单做一些知识的铺垫,否则不好描述.这里面涉及到的知识点有Spring的事务传播机制、数据库的隔离级别等.

本篇重点是解决同事遇到的问题,因为这两个知识点都先简单谈谈,只为引出主题.后面这两个会专门用一篇来讲

Spring的事务传播机制

Sring的事务传播机制有七种,本文涉及到的有两种

REQUIRED : 用得最多(估计高达90%),也是默认的模式.若当前没有事务,则新建事务,若当前已存在一个事务, 则加入到该事务中

REQUIRES_NEW : 新建一个事务

Spring的事务传播机制.后面我会用一篇文章专门来讲,给大家列各种典型的题型,按照高中的题型训练模式,彻底弄懂Spring的传播机制,即使在各种复杂嵌套 + try场景下也能云淡风轻地确定回滚情况.包括解析之前非常经典的一道面试题

做51次操作,前面50次成功,第51次失败,全部回滚
做51次操作,前面50次成功,第51次失败,只回滚第51次,全面50次照常提交

事务的隔离级别

考虑到部分同学英文问题,我特意标记了中文

1.Read Uncommitted: 读未提交

这个基本不可能用,从字面意思你就知道了,读到别人还未提交的数据,别人都没提交,你怎么知道别人接下来是要提交还是回滚?既然不知道你就读,自然会有问题.这个问题就是我们说的脏读.

2.Serializable: 串行化

其实就是同步化,性能太差,基本不可能用这个.但是这个是唯一能解决幻读问题的.

画图分析

剩下两种隔离级别

Read Committed: 读已提交
Read Repeatable: 可重复读

就比较重要了,我们画图来分析

比如我问,当t4时,查询出来的数据,name是大肥朝还是toby.其实你内心就不是很确定了,但是我如果把提交事务这几个字加粗标红,然后引诱一下,绝大多数同学根本把持不住!!!

既然都提交事务了,那读出来的自然是toby啦.

其实t4读出来是toby还是大肥朝这个取决与你用的是读已提交、可重复读.其实你从这个中文名称都可以猜到了,如果是读已提交,那么查出来的就是toby.如果是可重复读.读出来的自然就是大肥朝. MySQL默认用的是可重复读.Oracle默认用的是读已提交.

温馨提示: 这个后面也可以考虑再写一篇详细讲一下这个隔离级别,因为一般问到可重复读,有深度的面试官会继续追问,可重复读是如何实现的?具体怎么实现的我们可以先关注肥朝公众号,后面再具体说数据库的MVCC机制

问题描述

由于业务具有一定的复杂度,不利于大家观看,因此我这里特意抽象简化了模型.

首先,我先把数据库的隔离级别改成读已提交.截图为证:

那么问题来了,请问步骤3查询出来的数据是什么呢.我们一起来见证

见证答案

1.查询完数据,准备更新数据

2.更新完成提交了事务,我们看得出此时数据库已经改成了toby

3.震惊!查出来的数据竟然是大肥朝

这个时候似乎就不厚道了,肥朝你前面怎么说的,你前面说读已提交读出来的是别人已经提交的,那么应该是toby才对啊,怎么还是大肥朝?.

开始排查

我们把配置文件设置成`debug级别一切就豁然开朗了

logging.level.com.toby.demo.dao=debug
logging.level.org.mybatis=debug

这里我特意用不同颜色给大家标记清楚了,其实看到只输出两次SQL日志大家就知道了.第三次查询没有输出SQL,这很明显是用到了Mybatis的缓存了.再根据我标记的SqlSession信息来看,这里就是用到了Mybatis的一级缓存

解决办法

解决办法有很多,我们知道Mybatis一级缓存的作用域是SqlSession,那么只要两次查询是不同的SqlSession那自然这个一级缓存就失效了.一级缓存失效了.就会查询两次,输出两次sql.这个时候是toby还是大肥朝就真的取决于我前面说的隔离级别了.比如一个简单的改法是

改法有很多,具体根据那么的业务来就可以了,当然也可以采用上面那种

写在最后

肥朝是一个专注于原理、源码、开发技巧的技术公众号，号内原创专题式源码解析、真实场景源码原理实战（重点）。扫描下面二维码关注肥朝，让本该造火箭的你，不再拧螺丝！