栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 软件开发 > 后端开发 > Java

记录一次mybatis缓存和事务传播行为导致ut挂的排查过程

Java 更新时间: 发布时间: IT归档 最新发布 模块sitemap 名妆网 法律咨询 聚返吧 英语巴士网 伯小乐 网商动力

记录一次mybatis缓存和事务传播行为导致ut挂的排查过程

起因

rhea项目有两个ut一直都是挂的,之前也经过几个同事排查过,但是都没有找到解决办法,慢慢的这个问题就搁置了。因为之前负责rhea项目的同事离职,我临时接手了这个项目,刚好最近来了一个新同事在做新的功能开发的时候遇到了这个问题,于是我就接了一个锅,最终证明这个锅很好玩。

rhea是一个典型的使用mybatis orm的springboot项目,我们使用h2内存数据库做单元测试,每个单元测试都在一个事务内,都由Transactional进行注解。testGetBGWechatAccountByOpenid这个ut的核心调用链如下

调用深度较深,并且有多处使用到了事务,其中basePlatformUserService.insert这个方法用到了Propagation.REQUIRES_NEW,也就是图中最右边的这个链路中最终插入了一个PlatformUser

ut代码如下:

    @Test
		@Transactional
    public void testGetBGWechatAccountByOpenid() {
 OpenidRo openidRo = OpenidRo.builder()
     .openid(openidZmall)
     .appId(appIdZmall)
     .unionid(unionid)
     .openAppId(openAppId)
     .platformCategory(PlatformCategoriesEnum.Zmall.getValue())
     .service(ServicesEnum.Server.getValue())
     .serviceBusinessGroupId(serviceBusinessGroup2)
     .alived(false)
     .build();
 RheaAccount rheaAccount = platformUserService.getAccountByOpenId(openidRo);
 Assert.assertEquals(rheaAccount.getPhone(), phone2);

 RheaPlatformUser platformUser = platformUserMapper.getByOpenIdAndBG(
     openidZmall, appIdZmall, serviceBusinessGroup2, ServicesEnum.Server.getValue());
 Assert.assertEquals(rheaAccount.getId(), platformUser.getAccountId());

    }

但是在ut里面使用getByOpenIdAndBG查询platformUser却是null导致最终platformUser.getAccountId()这个方法抛出了NPE。

知识储备

排查这个问题会用到以下两个知识点

  • 事务传播行为-Propagation
  • mybatis缓存
  • 事务和mybatis Session的关联
事务传播行为

Springboot的Transactional的实现包含两部分,一个部分是事务传播行为,一个部分是数据库隔离级别,代码如下:

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@documented
public @interface Transactional {
    @AliasFor("transactionManager")
    String value() default "";

    @AliasFor("value")
    String transactionManager() default "";

    Propagation propagation() default Propagation.REQUIRED;

    Isolation isolation() default Isolation.DEFAULT;
    
    ...

数据库隔离级别默认是Isolation.DEFAULT,也就是使用数据库自身的隔离级别,Mysql的默认隔离级别是REPEATABLE_READ可重复读,Oracle的默认事务隔离级别是读已提交READ_COMMITTED。具体的隔离级别不在此讨论。我们需要关注事务的传播行为,也就是Propagation。Propagation实现如下:

public enum Propagation {
    REQUIRED(0),
    SUPPORTS(1),
    MANDATORY(2),
    REQUIRES_NEW(3),
    NOT_SUPPORTED(4),
    NEVER(5),
    NESTED(6);

    private final int value;

    private Propagation(int value) {
 this.value = value;
    }

    public int value() {
 return this.value;
    }
}

这里我们只是用到了REQUIRED和REQUIRED_NEW,REQUIRED也是默认的传播行为,这两个传播行为的区别在于:

  • REQUIRED:默认的spring事务传播级别,使用该级别的特点是,如果上下文中已经存在事务,那么就加入到事务中执行,如果当前上下文中不存在事务,则新建事务执行。所以这个级别通常能满足处理大多数的业务场景
  • REQUIRED_NEW:从字面即可知道,new,每次都要一个新事务,该传播级别的特点是,每次都会新建一个事务,并且同时将上下文中的事务挂起,执行当前新建事务完成以后,上下文事务恢复再执行。
    • 只有在被调用方法中的数据库操作需要保存到数据库中,而不管覆盖事务的结果如何时,才应该使用 REQUIRES_NEW 事务属性
    • 举个栗子:假设尝试的所有股票交易都必须被记录在一个审计数据库中。出于验证错误、资金不足或其他原因,不管交易是否失败,这条信息都需要被持久化。如果没有对审计方法使用 REQUIRES_NEW 属性,审计记录就会连同尝试执行的交易一起回滚。使用 REQUIRES_NEW 属性可以确保不管初始事务的结果如何,审计数据都会被保存
mybatis缓存

Mybatis-config.xml中可以配置mybatis的本地缓存范围localCacheScope。

mybatis官网解释:MyBatis 利用本地缓存机制(Local Cache)防止循环引用(circular references)和加速重复嵌套查询。 默认值为 SESSION,这种情况下会缓存一个会话中执行的所有查询。 若设置值为 STATEMENT,本地会话仅用在语句执行上,对相同 SqlSession 的不同调用将不会共享数据。

用白话解释:

  • SESSION范围的缓存:在同一个SqlSession中多次查询会缓存的mapper中的方法,经过验证,key是单个查询方法
    • 连续查询则后续的查询会使用第一个查询的缓存结果——debug时无法找到查询的sql日志
    • 间断的查询则会实际执行每个查询操作——可以找到每个查询的sql日志
    • 连续的定义是:在当前Session中执行DML操作,或者开启了其他Session执行了DML操作,都认为是连续
  • STATEMENT范围的缓存:本质是不使用缓存

在新版本的mysql中数据库自身有自己的缓存,我们并不需要Mybatis的缓存,而且Mybatis不是最底层的缓存,因为多个Session的存在,往往导致一些问题。

修改mybatis的默认缓存范围可以在Mybatis-config.xml中加入以下配置:



使用以下配置可以打印出mybatis执行时的操作log和sql语句:


事务和mybatis Session的关联

开启一个新的事务并且在新的事务中首次执行mybatis操作时会开启新的mybatis Session,因此在REQUIRES_NEW中执行mybatis操作一定会开启新的Session

排查过程
  1. 确保mapper方法对应的sql是对的
  2. 将使用REQUIRES_NEW的方法改为默认的REQUIRED,发现能查询到platformUser
  3. 在ut中使用其他方法查询插入的platformUser,发现能查询到
  4. mybatis配置加上日志,debug发现ut中的查询platformUserMapper.getByOpenIdAndBG发现没有打印sql
  5. 猜测可能是查询是用了mybatis缓存,取消缓存发现可以查询到真实记录
  6. 分析:REQUIRES_NEW开启的新事务中开启的新Session插入的记录并没有打破老Session缓存的查询结果,因此在老Session中使用相同的查询语句是查询不到真实记录的

具体的debug日志如下:

红框中的就是最外层的事务开启的老session,绿色框是中间REQUIRES_NEW新事务中开启的新Session。所以对于红框这个Session而言,它并不知道已经发生了DML操作,因此在后续继续查询时会使用最开始的查询结果,也就是null。

这种问题通常发生在getOrCreate操作中。

解决

去掉Mybatis层面的缓存



解决这个问题对于REQUIRES_NEW这个传播行为的理解就更深刻了。


参考:

  1. 了解事务陷阱:https://www.ibm.com/developerworks/cn/java/j-ts1.html
  2. Spring五个事务隔离级别和七个事务传播行为:https://blog.csdn.net/caoxiaohong1005/article/details/79984912
  3. Innodb中的事务隔离级别和锁的关系:https://tech.meituan.com/2014/08/20/innodb-lock.html
  4. Mybatis XML配置:https://mybatis.org/mybatis-3/zh/configuration.html

记得帮我点赞哦!

念念不忘,必有回响,小伙伴们帮我点个赞吧,非常感谢。

我是职场亮哥,YY高级软件工程师、四年工作经验,拒绝咸鱼争当龙头的斜杠程序员。

听我说,进步多,程序人生一把梭

如果有幸能帮到你,请帮我点个【赞】,给个关注,如果能顺带评论给个鼓励,将不胜感激。

本人所有文章、回答都与版权保护平台有合作,著作权归职场亮哥所有,未经授权,转载必究!

转载请注明:文章转载自 www.mshxw.com
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号