spring-data-jpa 事物中修改属性自动更新update问题

问题还原

项目orm层用的是spring-data-jpa,服务端接口实现的是树节点间的拖拽功能,测试环境联调发现异常问题,其中拖拽到目标目录后节点名称总会重名,重名规则是originName转化为originName(n)

    @Transactional(rollbackFor = Exception.class)
    public void move(MoveWorkSpaceDto moveWorkSpaceDto) {
        /***
         * 个人空间节点移动
         * 1、源节点移动到空目录,那么目标父节点必传,前置和后置节点都为空
         * 2、源节点移动到非空目录:
         *   2.1、移动到目标目录的第一个节点,那么后置节点必传,前置节点为空
         *   2.2、移动到目标目录的最后个节点,那么前置节点毕传,后置节点为空
         *   2.3、移动到目标目录的中间节点,那么前置节点和后置节点都要传入
         * 3、节点拖动到目录中,此时不知道目录是否非空,前置后置节点都不传,服务器追加到目录的最后个节点
         */

        log.info(">>>MoveParams: [{}]", JSONObject.toJSONString(moveWorkSpaceDto));
        WorkSpaceEntity sourceEntity = workSpaceRepository.findById(moveWorkSpaceDto.getSourceWorkId()).orElse(null);
        if (sourceEntity == null) {
            throw new PublicsException("源工作空间节点不存在!");
        }
        WorkSpaceEntity parentEntity = workSpaceRepository.findById(moveWorkSpaceDto.getDestParentId()).orElse(null);
        if (parentEntity == null) {
            throw new PublicsException("目标父工作空间节点不存在!");
        }
        log.info(">>>>Noooooooo<<<<<");
        sourceEntity.setParentId(parentEntity.getId());
        log.info(">>>>UpdateNow<<<<<");
        Long cnt = workSpaceRepository.countAllByParentIdAndSpaceName(parentEntity.getId(), sourceEntity.getSpaceName());
        log.info("destParentId: [{}], spaceName: [{}], destCount: [{}]", parentEntity.getId(), sourceEntity.getSpaceName(), cnt);
        if (cnt > 0L) {
            String newName = RenameUtil.rename(sourceEntity.getSpaceName(), sourceEntity.getRunType(), cnt);
            sourceEntity.setSpaceName(newName);
        }
        if (moveWorkSpaceDto.getFrontWorkId() == null && moveWorkSpaceDto.getPostWorkId() == null) {
            List<WorkSpaceEntity> children = workSpaceRepository.findByParentIdOrderBySortIndexDesc(
                    moveWorkSpaceDto.getDestParentId());
            if (CollectionUtils.isEmpty(children)) {
                sourceEntity.setSortIndex(sourceEntity.getId() * SORT_INDEX_STEP);
            } else {
                sourceEntity.setSortIndex(children.get(0).getSortIndex() + SORT_INDEX_STEP);
            }
        } else if (moveWorkSpaceDto.getFrontWorkId() != null && moveWorkSpaceDto.getPostWorkId() == null) {
            WorkSpaceEntity frontEntity = getFrontEntity(moveWorkSpaceDto);
            sourceEntity.setSortIndex(frontEntity.getSortIndex() + SORT_INDEX_STEP);
        } else if (moveWorkSpaceDto.getFrontWorkId() == null && moveWorkSpaceDto.getPostWorkId() != null) {
            WorkSpaceEntity postEntity = getPostEntity(moveWorkSpaceDto);
            sourceEntity.setSortIndex(postEntity.getSortIndex() - SORT_INDEX_STEP);
        } else {
            WorkSpaceEntity frontEntity = getFrontEntity(moveWorkSpaceDto);
            WorkSpaceEntity postEntity = getPostEntity(moveWorkSpaceDto);
            sourceEntity.setSortIndex((frontEntity.getSortIndex() + postEntity.getSortIndex()) / 2);
        }
        workSpaceRepository.save(sourceEntity);
    }

排查后发现代码逻辑正常,于是加日志定位,果然在更新项目前多了update操作,具体位置如下:


image.png

说明entity实体更新属性后,jpa自动执行了update属性,导致count判重始终大于0。

问题原因

jpa在hibernate上更进一步,我把单表的查询逻辑定义在Repository层的方法上,不用谢SQL,简单明了,不曾想,忽略的hibernate的entity在session的3种状态。

  1. 临时态,刚创建new的对象,还没有持久化,session缓存中也没有。
  2. 游离态,已经持久化,但不在session缓存中。
  3. 持久态,已经持久化,也在session缓存中。

问题原因明确,sourceEntity在持久态,修改属性自然会更新到数据库,判重查询已经更新了,查的还是自己,所以总是误认为有重复节点。

解决办法--隔离entity

避开session中缓存的sourceEntity的修改,创建新entity,修改临时态的entity,设置好属性后再调用save更新数据


    @Transactional(rollbackFor = Exception.class)
    public void move(MoveWorkSpaceDto moveWorkSpaceDto) {
        /***
         * 个人空间节点移动
         * 1、源节点移动到空目录,那么目标父节点必传,前置和后置节点都为空
         * 2、源节点移动到非空目录:
         *   2.1、移动到目标目录的第一个节点,那么后置节点必传,前置节点为空
         *   2.2、移动到目标目录的最后个节点,那么前置节点毕传,后置节点为空
         *   2.3、移动到目标目录的中间节点,那么前置节点和后置节点都要传入
         * 3、节点拖动到目录中,此时不知道目录是否非空,前置后置节点都不传,服务器追加到目录的最后个节点
         */

        log.info(">>>MoveParams: [{}]", JSONObject.toJSONString(moveWorkSpaceDto));
        WorkSpaceEntity sourceEntity = workSpaceRepository.findById(moveWorkSpaceDto.getSourceWorkId()).orElse(null);
        if (sourceEntity == null) {
            throw new PublicsException("源工作空间节点不存在!");
        }
        WorkSpaceEntity parentEntity = workSpaceRepository.findById(moveWorkSpaceDto.getDestParentId()).orElse(null);
        if (parentEntity == null) {
            throw new PublicsException("目标父工作空间节点不存在!");
        }
        WorkSpaceEntity updateEntity = new WorkSpaceEntity();
        BeanUtils.copyProperties(sourceEntity, updateEntity);

        Long cnt = workSpaceRepository.countByParentIdAndSpaceName(parentEntity.getId(), updateEntity.getSpaceName());
        log.info("destParentId: [{}], spaceName: [{}], destCount: [{}]", parentEntity.getId(), updateEntity.getSpaceName(), cnt);
        if (cnt > 0L) {
            String newName = RenameUtil.rename(updateEntity.getSpaceName(), updateEntity.getRunType(), cnt);
            updateEntity.setSpaceName(newName);
        }
        if (moveWorkSpaceDto.getFrontWorkId() == null && moveWorkSpaceDto.getPostWorkId() == null) {
            List<WorkSpaceEntity> children = workSpaceRepository.findByParentIdOrderBySortIndexDesc(
                    moveWorkSpaceDto.getDestParentId());
            if (CollectionUtils.isEmpty(children)) {
                updateEntity.setSortIndex(updateEntity.getId() * SORT_INDEX_STEP);
            } else {
                updateEntity.setSortIndex(children.get(0).getSortIndex() + SORT_INDEX_STEP);
            }
        } else if (moveWorkSpaceDto.getFrontWorkId() != null && moveWorkSpaceDto.getPostWorkId() == null) {
            WorkSpaceEntity frontEntity = getFrontEntity(moveWorkSpaceDto);
            updateEntity.setSortIndex(frontEntity.getSortIndex() + SORT_INDEX_STEP);
        } else if (moveWorkSpaceDto.getFrontWorkId() == null && moveWorkSpaceDto.getPostWorkId() != null) {
            WorkSpaceEntity postEntity = getPostEntity(moveWorkSpaceDto);
            updateEntity.setSortIndex(postEntity.getSortIndex() - SORT_INDEX_STEP);
        } else {
            WorkSpaceEntity frontEntity = getFrontEntity(moveWorkSpaceDto);
            WorkSpaceEntity postEntity = getPostEntity(moveWorkSpaceDto);
            updateEntity.setSortIndex((frontEntity.getSortIndex() + postEntity.getSortIndex()) / 2);
        }
        updateEntity.setParentId(parentEntity.getId());
        workSpaceRepository.save(updateEntity);
    }

场景复现

  1. 无事物的service中修改
    public void test() {
        CronTaskEntity cronTaskEntity = cronTaskRepository.findById(18L).orElse(null);
        // 更新记录
        cronTaskEntity.setUsername("鲁班七号");
        CronTaskEntity newEntity = cronTaskRepository.findById(18L).orElse(null);
        Assert.isTrue(cronTaskEntity.getUsername().equals(newEntity.getUsername()), "查询‘鲁班七号’没有更新啊");
    }

运行后:
Caused by: java.lang.IllegalArgumentException: 查询‘鲁班七号’没有更新啊
  1. 有事物中的service修改
    @Transactional
    public void test() {
        CronTaskEntity cronTaskEntity = cronTaskRepository.findById(18L).orElse(null);
        // 更新记录
        cronTaskEntity.setUsername("鲁班七号");
        CronTaskEntity newEntity = cronTaskRepository.findById(18L).orElse(null);
        Assert.isTrue(cronTaskEntity.getUsername().equals(newEntity.getUsername()), "查询‘鲁班七号’没有更新啊");
    }

运行后:
Hibernate: update `cron_task` set `createtime`=?, `updatetime`=?, `is_deleted`=?, `cron_expression`=?, `remark`=?, `staff_id`=?, `tag_id`=?, `username`=? where `id`=?

通过

由此可见,事物中会保存entity的缓存,修改entity属性引起jpa自动update,因此避免误操作,建议创建临时态的entity修改属性。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,088评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,715评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,361评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,099评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 60,987评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,063评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,486评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,175评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,440评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,518评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,305评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,190评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,550评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,880评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,152评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,451评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,637评论 2 335