如何解決spring-data-jpa事物中修改屬性自動更新update問題

小編給大家分享一下如何解決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操作，具體位置如下：

說明entity實體更新屬性后，jpa自動執行了update屬性，導致count判重始終大于0。

問題原因

jpa在hibernate上更進一步，我把單表的查詢邏輯定義在Repository層的方法上，不用謝SQL，簡單明了，不曾想，忽略的hibernate的entity在session的3種狀態。

• 臨時態，剛創建new的對象，還沒有持久化，session緩存中也沒有。

• 游離態，已經持久化，但不在session緩存中。

• 持久態，已經持久化，也在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: 查詢‘魯班七號'沒有更新啊

2、有事物中的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修改屬性。

以上是“如何解決spring-data-jpa事物中修改屬性自動更新update問題”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！