共计 838 个字符,预计需要花费 3 分钟才能阅读完成。
前言
这次测试的时候遇到了一个懒查问异样,懒查问谬误在上个月也遇到过,过后参考网上意见敞开实体间懒查问。一周汇报的时候,老师倡议我应用 @Transactional 事务注解,过后也顺利解决了。这次又遇到一个比较复杂的通过 @Transactional 事务注解却解决不了。
解决过程
次要波及办法大略是这样的,有一个队列存储元素,办法一是一个后盾接口,负责将前台传入元素入队,办法二执行定时工作,每隔一段时间查看队列是否为空,如果不为空,则执行相应办法。执行相应办法时报错,说这个队头元素的关联实体的关联实体的关联实体报懒查问谬误。我尝试在办法二上退出 @Transactional 事务注解,然而并没有解决问题,还是报雷同谬误。我也尝试在办法一上退出事务注解,也没有解决问题。
于是我通过上次谬误,在相应对应实体上敞开懒查问,问题解决。然而这是单纯的敞开懒查问会徒增数据库压力。想着通过更好的方法解决。
而后就遇到了奇怪的事件。
当我在办法一上打断点查看入队的元素是否有问题时,通过下方显示 district.children 有相应对象,传入的值没有问题
而后在办法二上打断点查看获取的元素是否又问题,通过下方显示还是没有问题(运行时是这里报错的)。
第二次没有查看断点一元素,间接跳过,查看断点二,发现报懒查问谬误。
解决
想到用到关联实体类的时候从新从数据库查问一下。
// 避免懒查问异样
WebUser webUser = this.webUserService.getById(historyExportExcel.getWebUser().getId());
List<District> manageBuildings = this.districtService.getManageBuildingsWithWebUser(webUser);
胜利解决。
认真一想,我并没有将元素存入数据库中,而是长期保留在队列中,实质上保留在服务器内存中,然而也会有数据库相干谬误,难道在 java 在底层也对类存储实现序列化存储?
正文完