Spring Boot中建议关闭Open-EntityManager-in-view
前言
一天,开发突然找过来说KLock分布式锁失效了,高并发情况下没有锁住请求,导致数据库抛乐观锁的异常。一开始我是不信的,KLock是经过线上大量验证的,怎么会出现这么低级的问题呢?然后,协助开发一起排查了一下午,最后经过不懈努力和一探到底的摸索精神最终查明不是KLock锁的问题,问题出在Spring Data Jpa的Open-EntityManager-in-view这个配置上,这里先建议各位看官关闭Open-EntityManager-in-view,具体缘由下面慢慢道来
问题背景
假设我们有一张账户表account,业务逻辑是先用id查询出来,校验下,然后用于其他的逻辑操作,最后在用id查询出来更新这个account,业务流程如下:
- 请求一:查询id =6的记录,此时JpaVersion =6,业务处理,再次查询id =6的记录,JpaVersion =6,然后更新数据提交
- 请求二:查询id =6的记录,此时JpaVersion =6, 业务处理,此时请求一结束了,再次查询id=6的记录,JpaVersion =6,更新数据提交失败
首先,请求一和请求二是模拟的并发请求,然后问题出在,当请求一事务正常提交结束后,请求二最后一次查询的JpaVersion还是没有变化,导致了当前版本和数据库中的版本不一致二抛乐观锁异常,而KLock锁是加在第二次查询更新的方法上面的,可以肯定KLock锁没有问题,锁住了请求,直到请求一结束后,请求二才进方法。
2019-11-20 18:32:00.573 [/] pay-settlement-app [http-nio-8086-exec-4] ERROR c.k.p.p.s.a.e.ControllerExceptionHandler - Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; nested exception is org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 org.springframework.orm.ObjectOptimisticLockingFailureException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; nested exception is org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 at org.springframework.orm.jpa.vendor.HibernateJpaDialect.convertHibernateAccessException(HibernateJpaDialect.java:320) at org.springframework.orm.jpa.vendor.HibernateJpaDialect.translateExceptionIfPossible(HibernateJpaDialect.java:244) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.translateExceptionIfPossible(AbstractEntityManagerFactoryBean.java:488) at org.springframework.dao.support.ChainedPersistenceExceptionTranslator.translateExceptionIfPossible(ChainedPersistenceExceptionTranslator.java:59) at org.springframework.dao.support.DataAccessUtils.translateIfNecessary(DataAccessUtils.java:213) at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:147) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:133) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
Open-EntityManager-in-view的前世今生
Open-EntityManager-in-view简述下就是在视图层打开EntityManager,spring boot2.x中默认是开启这个配置的,作用是绑定EntityManager到当前线程中,然后在试图层就开启Hibernate Session。用于在Controller层直接操作游离态的对象,以及懒加载查询。在应用配置中可以使用spring.jpa.open-in-view=true/false来开启和关闭它,最终控制的其实是OpenEntityManagerInViewInterceptor拦截器,如果开启就添加此拦截器,如果关闭则不添加。然后在这个拦截器中会开启连接,打开Session,业务Controller执行完毕后关闭资源。打开关闭代码如下:
public void preHandle(WebRequest request) throws DataAccessException { String key = getParticipateAttributeName(); WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request); if (asyncManager.hasConcurrentResult() && applyEntityManagerBindingInterceptor(asyncManager, key)) { return; } EntityManagerFactory emf = obtainEntityManagerFactory(); if (TransactionSynchronizationManager.hasResource(emf)) { // Do not modify the EntityManager: just mark the request accordingly. Integer count = (Integer) request.getAttribute(key, WebRequest.SCOPE_REQUEST); int newCount = (count != null ? count + 1 : 1); request.setAttribute(getParticipateAttributeName(), newCount, WebRequest.SCOPE_REQUEST); } else { logger.debug("Opening JPA EntityManager in OpenEntityManagerInViewInterceptor"); try { EntityManager em = createEntityManager(); EntityManagerHolder emHolder = new EntityManagerHolder(em); TransactionSynchronizationManager.bindResource(emf, emHolder); AsyncRequestInterceptor interceptor = new AsyncRequestInterceptor(emf, emHolder); asyncManager.registerCallableInterceptor(key, interceptor); asyncManager.registerDeferredResultInterceptor(key, interceptor); } catch (PersistenceException ex) { throw new DataAccessResourceFailureException("Could not create JPA EntityManager", ex); } } } public void afterCompletion(WebRequest request, @Nullable Exception ex) throws DataAccessException { if (!decrementParticipateCount(request)) { EntityManagerHolder emHolder = (EntityManagerHolder) TransactionSynchronizationManager.unbindResource(obtainEntityManagerFactory()); logger.debug("Closing JPA EntityManager in OpenEntityManagerInViewInterceptor"); EntityManagerFactoryUtils.closeEntityManager(emHolder.getEntityManager()); } }
在Spring MVC时代,懒加载的问题也比较常见,那个时候是通过定义一个OpenEntityManagerInViewFilter的过滤器解决问题的,效果和拦截器是一样的,算是同门师兄弟的关系。如果没有配置,在懒加载的场景下就会抛出LazyInitializationException的异常。
问题的真实原因
了解了Open-EntityManager-in-view后,我们来分析下具体的原因。由于在view层就开启Session了,导致了同一个请求第二次查询时根本就没走数据库,直接获取的Hibernate Session缓存中的数据,此时无论怎么加锁,都读不到数据库中的数据,所以只要有并发就会抛乐观锁异常。这让我联想到了老早前一个同事和我说的他们遇到的一个并发问题,即使给@Transactional事务的隔离级别设置为串行化执行,还是会报乐观锁的异常。有可能就是这个问题导致的,在这个案例中,加锁不好使,即使使用数据库的串行化隔离级别也不好使。因为第二次查询根本就不走数据库了。
解决方案
真实原因已经定位到了,KL博主给出了几种方案解决问题,如下:
- 方案一、将KLock前置,把加分布式锁的逻辑移到第一次使用id查询之前,即让查询发生在别的请求事务结束之前,这样无论第一次查询还是第二次查询获取到的都是别的事务已提交的内容
- 方案二、使用spring.jpa.open-in-view=false关闭,这个方案比较简单粗暴,但是影响会比较大,其他的代码很可能已经依赖了懒加载的功能特性,贸然去掉会带来大量的回归测试工作,所以虽然博主建议关闭这个特性,但是在已经使用了的系统中不推荐
- 方案三、局部控制Open-EntityManager-in-view行为,就是人为编码控制EntityManager的绑定,在有影响的地方先取消绑定,然后执行完后在添加回来,不添加回来会导致Jpa自己的解绑逻辑报错。代码如下:
/** * @author: kl @kailing.pub * @date: 2019/11/20 */ @Component public class OpenEntityManagerInViewManager extends EntityManagerFactoryAccessor { public void cancel() { EntityManagerFactory emf = obtainEntityManagerFactory(); EntityManagerHolder emHolder = (EntityManagerHolder) TransactionSynchronizationManager.unbindResourceIfPossible(emf); EntityManagerFactoryUtils.closeEntityManager(emHolder.getEntityManager()); } public void add() { EntityManagerFactory emf = obtainEntityManagerFactory(); if (!TransactionSynchronizationManager.hasResource(emf)) { EntityManager em = createEntityManager(); EntityManagerHolder emHolder = new EntityManagerHolder(em); TransactionSynchronizationManager.bindResource(emf,emHolder); } } }
- 方案四:方案三为了达到效果有点费劲哈,其实还有一种方案,在第二次查询前使用EntityManager的clear清除Session缓存即可,
建议关闭Open-EntityManager-in-view
在Spring boot2.x中,如果没有显示配置spring.jpa.open-in-view,默认开启的这个特性Spring会给出一个警告提示:
logger.warn("spring.jpa.open-in-view is enabled by default. " + "Therefore, database queries may be performed during view " + "rendering. Explicitly configure spring.jpa.open-in-view to disable this warning");
用来告诉你,我开启这个特性了,你可以显示配置来关闭这个提示。博主猜测就是告知用户,你可能用不着吧。确实,现在微服务中的应用在使用Spring Data JPA时,已经很少使用懒加载的特性了。而且如果你的代码规范点,也用不着直接在Controller层写Dao层的代码。总结下就是根本就不需要Open-EntityManager-in-view的特性,然后它还有副作用,开启Open-EntityManager-in-view,会使数据库租用连接时长变长,长时间占用连接直接影响整体事务吞吐量。然后一不小心就会陷进Session缓存的坑里。所以,新项目就直接去掉吧,老项目去掉后回归验证下
结语
因为对业务不熟悉,不知道业务逻辑中查询了两次相同的实体,导致整个排错过程比较曲折。先是开发怀疑锁的问题,验证锁没问题后,又陷进了IDEA断点的问题,因为模拟的并发请求,断点释放一次会通过多个请求,看上去就像很多请求没进来一样。然后又怀疑了事务和加锁前后的逻辑问题,如果释放锁在释放事务前就会有问题,将断点打在了JDBC的Commit方法里,确认了这个也是正常的。最后才联想到Spring boot中默认开启了spring.jpa.open-in-view,会不会有关系,也不确定,怀着死马当活马医的心态试了下,果然是这个导致的,这个时候只知道是这个导致的,还没发现是这个导致的Session问题,以为是进KLock前就开启了事务锁定了数据库版本记录,所以查询的时候返回的老的记录,最后把事务串行化后还不行,才发现的业务查询了两次进而发现了Session缓存的问题。至此,水落石出,所有问题迎刃而解。
作者简介:
陈凯玲,2016年5月加入凯京科技。现任凯京科技研发中心架构组经理,救火队队长。独立博客KL博客(http://www.kailing.pub)博主。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
2019中德中小企业合作交流大会·AI分论坛,看AI如何赋能传统企业。
人工智能作为新一轮产业变革的核心驱动力,催生新技术、新产品、新产业、新模式,谷歌CEO认为AI的重要性可以与电力和火相媲美。 全球大部分最有影响力的技术公司都表现出对人工智能的狂热,11月12日,2019中德中小企业合作交流大会·AI分论坛在泉城济南成功举办。 本次论坛由济南高新技术产业开发区管委会、济南市科学技术局、山东国惠安创智能物联发展有限公司主办,济南高新区齐鲁软件园发展中心承办、安创加速器(Arm Accelerator)。 大会现场高朋满座,本次论坛以“AI聚能·智领未来”为主题,围绕AI技术创新与产业应用落地两大核心展开讨论,旨在进一步加快当地产业升级与创新生态建设,赋能济南战略产业集群发展,助力当地产业深度融入全球产业链,加速制造业转型升级。 中德中小企业领导人和技术专家高朋满座 大会现场,济南高新区党工委副书记、管委会
- 下一篇
golang 高频服务延时抖动追因
一,背景 策略组同学反馈有个服务上线后 redis 写超时非常严重,严重到什么地步呢,写redis 毛刺超过100ms! 而且不是随机出现,非常多,而且均匀,导致整个接口超时严重。因为用的redis 库是由我们组维护,所以任务落我们组小伙伴头上了。 这个项目有非常复杂的业务逻辑,有密集型io(调度问题)+定时任务(cpu问题)+常驻内存cache(gc问题),频繁访问redis,在定时逻辑中,业务逻辑需要一个request 可能达到上千次redis Hmget+get(先不讨论合理性)。 背景比较复杂, 是个golang 服务,接口延迟要求百ms级。 go version : 1.8,机器是8核+16G 容器,没有开runtime 监控,redis 的同事初步反馈没有slowlog。因为rd 也追了很久,到我们这边来的时候,redis 的超时指标监控已经给我们加了。 redis get 接口的耗时监控显示如下,因为高频请求,大部分耗时是小于10ms 的,但是这毛刺看着非常严重,是不可忍受了。 系统cpu问题比较严重,抖动非常大,内存并没有太大问题,但是占用有点大,比较有意思的事,因为用...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果