BookmarkCount 동시성 관련 문제 해결 방안

[cpot5620]

DB 역정규화에 따라, 변경 감지를 사용하면 동시성 이슈가 발생합니다.
이로 인해, PR에서 이야기 나누었던 해결 방안은 JPQL로 처리였습니다.
하지만, 단순히 JPQL로만 처리할경우 객체 지향적이지 못한(?) 코드가 탄생하게 됩니다.
그 예시를 아래 코드와 함께 설명드릴게요.

우선, BookmarkCount를 감소시키는 JPQL은 아래와 같이 구현하였습니다.

    // TopicRepoisotry.class

    @Modifying(clearAutomatically = true)
    @Query("update Topic t set t.bookmarkCount = t.bookmarkCount - 1 where t.id = :topicId")
    void decreaseBookmarkCountById(@Param("topicId") Long topicId);

우리는 위 메서드를 활용해서, 즐겨찾기를 제거하는 서비스 로직을 아래와 같이 작성하게 됩니다.

    public void deleteTopicInBookmark(AuthMember authMember, Long topicId) {
        validateBookmarkDeletingPermission(authMember, topicId);
        BookmarkId bookmarkId = BookmarkId.of(topicId, authMember.getMemberId());

        bookmarkRepository.deleteById(bookmarkId);
        topicRepository.decreaseBookmarkCountById(topicId); // 이 부분은 이벤트로 변경될 수도 있습니다.
    }

위 로직상에선 문제가 없지만, 만약 즐겨찾기 개수를 감소시키는 작업 외에 부가적인 작업을 수행해야한다면 어떻게 될까요 ?
정말 예상치 못한 문제를 맞닥뜨릴 수 있을지도 모릅니다.

위 코드를 그대로 가져와볼게요.

    public void deleteTopicInBookmark(AuthMember authMember, Long topicId) {
        validateBookmarkDeletingPermission(authMember, topicId);
        BookmarkId bookmarkId = BookmarkId.of(topicId, authMember.getMemberId());


        Topic topic = getTopicById(topicId);  // ---------------------(a)

        bookmarkRepository.deleteById(bookmarkId);
        topicRepository.decreaseBookmarkCountById(topicId);
        //JPQL로 처리하여 DB상에는 topicCount는 변경됨.
        // (a) 에서 조회한 topic 객체의 topicCount는 변경되지 않음.
    }

위와 같은 문제가 발생할 수 있을 것 같아요.
이를 해결하기 위해서는 아래와 같은 추가 작업을 수행하면 되긴 합니다.

    public void deleteTopicInBookmark(AuthMember authMember, Long topicId) {
        validateBookmarkDeletingPermission(authMember, topicId);
        BookmarkId bookmarkId = BookmarkId.of(topicId, authMember.getMemberId());


        Topic topic = getTopicById(topicId);  // ---------------------(a)

        bookmarkRepository.deleteById(bookmarkId);
        topicRepository.decreaseBookmarkCountById(topicId);
        topic.decreaseCount(); // 추가 작업
        //JPQL로 처리하여 DB상에는 topicCount는 변경됨.
        // (a) 에서 조회한 topic 객체의 메서드 호출을 통해 topicCount를 같이 감소 시켜줌.
    }

하지만, 위 코드는 동일한 작업을 중복해서 수행하는 듯하지 않나요 ?
물론, Service 계층에 두 작업을 수행하도록 하는 private 메서드를 작성해도 됩니다.
하지만, 이는 너무 Service에 의존적이지 않나 싶습니다. 또한, 다른 서비스 계층에서 중복되는 메서드를 여러번 작성하는 경우도 있을 것 같아요.

그래서, 생각한 방안이 Topic.decreaseCount() 메서드에 TopicRepository 인자를 넘겨주는 것인데요.

    // Topic.class

    public void decreaseBookmarkCount(TopicRepository topicRepository) {
        topicRepository.decreaseBookmarkCountById(id);
        bookmarkCount--;
    }

위처럼 메서드를 작성하면, 앞서 말씀드렸던 문제점들을 해결할 수 있을 것 같아요.
다만, 저희 프로젝트 코드에 위와 같은 방식으로 접근한 적이 없어서 디스커션을 작성하게 되었습니다.

위 방법과 관련하여 질문이나, 더 좋은 방법이 있으시다면 의견 부탁드릴게요.

[kpeel5839]

쥬니!

너무 좋은 아이디어입니다! 고민을 많이 해주셨나보군요.

다만 Entity 가 Repository 를 의존하는 것은 지금까지 시도해보지 방법이다보니 우려가 되는 것 같아요.

하지만, 현재로서는 Entity 가 Repository 를 의존했을 때 Topic 과 TopicRepository 간의 양방향 의존성이 생긴다는 것 이외의 문제점이 딱히 떠오르지 않네요.

아무래도 Repository 넘겨줘서 그냥 메서드 하나 호출하는 거니까요.

추후에 해당 의존관계가 유지보수에 영향을 주려나요?

킹치만, 저의 개인적인 생각으로는, 위 작업은 다른 애그리거트간의 상호작용이니, 말씀해주신 바와 같이 Event 를 발행하여, Topic 이 TopicRepository 를 의존하지 않으며, 특정 Service 에 의존하지 않는다는 두 마리의 토끼를 잡는 것이 좋지 않을까? 라는 생각도 해봅니다.

아래와 같은 형식으로요

@EventListener  
public void removeBookmark(BookmarkDeleteEvent event) {  
    Topic topic = event.topic();  
    topic.decreaseBookmarkCount();  
    topicRepository.decreaseBookmarkCountById(topic.getId());  
}

혹시 쥬니는 이벤트 발행방식보다, 위 방식을 택한 이유가 있을까요?

제가 고려하지 못한 사항이 있을까요?

있다면 죄송합니당 알러뷰

[cpot5620]

이벤트 발행은 고려했었어요 !!
설명을 좀 쉽게 하기 위해, 주석으로 이벤트로 변경할 수 있다고 얘기하긴 했는데 안 보셨나요 😠

매튜 질문에 대한 답변은 아래에 남겨놓을게요.

하지만, 현재로서는 Entity 가 Repository 를 의존했을 때 Topic 과 TopicRepository 간의 양방향 의존성이 생긴다는 것 이외의 문제점이 딱히 떠오르지 않네요.

매튜는 양방향 의존성을 없앰으로써 달성하려는 궁극적인 목표가 뭐라고 생각하시나요 !?

추후에 해당 의존관계가 유지보수에 영향을 주려나요?

매튜의 위 질문에서도 드러나듯, 코드의 변경점을 최소화 하기 위함이라고 생각해요 !
TopicRepository는 인터페이스이기도하고 크게 변경(확장이 아닌 수정)될 일이 없을 거라고 생각해요.

그렇다면, Topic이 변경되었을 때를 봐야할 것 같은데요.
해당 Entity에 필드가 변경될 경우는 양방향 의존관계가 아니더라도 TopicRepository에 작성된 JPQL은 변경이 필요하게 되요.

그래서.. 위 상황에서 발생하는 양방향 의존관계는 크게 문제가 없지 않을까 ? 였어요 !

혹시 쥬니는 이벤트 발행방식보다, 위 방식을 택한 이유가 있을까요?

우선, 매튜가 작성해주신 예시 코드에서는 예상치 못한 오류가 발생해요 !
topic.decreaseBookmarkCount를 호출하면 변경감지에 의해, update 쿼리 대상이 되어있는 상태에요.
이후, `topicRepository.decreaseBookmarkCountById()를 호출하게 되면, 해당 메서드를 호출하기 전에 영속성 컨텍스트가 flush되게 되는데요.
이로 인해, DB에는 2번의 decrease가 발생하게 되요 !
그래서 위의 두 메서드 호출 순서를 바꿔주어야 해요. (사실 이거 자체만으로 큰 문제인 것 같기도 합니다 ㅠㅠ)

매튜가 작성해주셨을때 발생한 휴먼 에러를 최대한 방지하기 위해서는 해당 로직을 entity에 숨겨놓는 것이 좋을 것 같다고 판단했어요.
아무래도 이벤트 로직보다는 Entity가 변경 가능성이 적다고 생각했거든요...

하지만, 지속적으로 고민하다보니까 제가 이야기 한 방식이 오버엔지니어링(?)이 아닐까 싶기도 해요.
BookmarkCount를 변경하고나서 Topic을 조회할 일이 뭐가 있을까 싶기도 하구요 ..
그런일이 발생한다면 그때가서 도입해도 되지 않을까 ? 싶어요 !
즉, 이벤트 발행을 통해 topicRepository.decreaseBookmarkCountById()` 메서드만 호출하는 방식으로 가는거죠 !

질문에 대한 답변은 얼추 남겨놓은 것 같은데, 추가로 궁금한 점이 있으시면 말씀해주세요.

[kpeel5839]

이벤트 발행은 고려했었어요 !!
설명을 좀 쉽게 하기 위해, 주석으로 이벤트로 변경할 수 있다고 얘기하긴 했는데 안 보셨나요 😠

킹치만, 저의 개인적인 생각으로는, 위 작업은 다른 애그리거트간의 상호작용이니, 말씀해주신 바와 같이 Event 를 발행하여 , Topic 이 TopicRepository 를 의존하지 않으며, 특정 Service 에 의존하지 않는다는 두 마리의 토끼를 잡는 것이 좋지 않을까? 라는 생각도 해봅니다.

말씀해주신 바와 같이.... Event 를 발행하여... 왜 제대로 안읽으셨죠?! 빨리 빵댕이나 흔드세요!

우선, 매튜가 작성해주신 예시 코드에서는 예상치 못한 오류가 발생해요 !
topic.decreaseBookmarkCount를 호출하면 변경감지에 의해, update 쿼리 대상이 되어있는 상태에요.
이후, `topicRepository.decreaseBookmarkCountById()를 호출하게 되면, 해당 메서드를 호출하기 전에 영속성 컨텍스트가 flush되게 되는데요.
이로 인해, DB에는 2번의 decrease가 발생하게 되요 !
그래서 위의 두 메서드 호출 순서를 바꿔주어야 해요. (사실 이거 자체만으로 큰 문제인 것 같기도 합니다 ㅠㅠ)

헐 맞네요 이 부분은 고려하지 못했어요

변경감지로 인해서 이런 문제가 발생하는군요

하지만, 지속적으로 고민하다보니까 제가 이야기 한 방식이 오버엔지니어링(?)이 아닐까 싶기도 해요.
BookmarkCount를 변경하고나서 Topic을 조회할 일이 뭐가 있을까 싶기도 하구요 ..
그런일이 발생한다면 그때가서 도입해도 되지 않을까 ? 싶어요 !

이 부분도 댓글 남기기전에 생각했지만, 그래도 방지하는 것이 좋다고 생각하긴 했어요.

하지만, 현재 오버엔지니어링이라고 판단되면 말씀하신 것처럼 Event 발행하면서 JPQL 로 Bookmark 카운트만 줄여도 괜찮을 것 같아요.

근데 갑자기 궁금한게 생겼어요

public void deleteTopicInBookmark(AuthMember authMember, Long topicId) {
    validateBookmarkDeletingPermission(authMember, topicId);
    BookmarkId bookmarkId = BookmarkId.of(topicId, authMember.getMemberId());


    Topic topic = getTopicById(topicId);  // ---------------------(a)

    bookmarkRepository.deleteById(bookmarkId);
    topicRepository.decreaseBookmarkCountById(topicId);     
    //JPQL로 처리하여 DB상에는 topicCount는 변경됨.
    // (a) 에서 조회한 topic 객체의 topicCount는 변경되지 않음.
}

a 에서 조회한 topic 객체의 bookmarkCount 가 변경되지 않아, 해당 메서드에서 Topic 을 재 사용할 때 문제가 되는 것 뿐만 아니라, 변경감지로 인하여 감소시킨 Bookmark Count 가 원래대로 돌아오는 현상이 발생하기도 할까요?

이건 순수 궁금증입니당.

[cpot5620]

하지만, 현재 오버엔지니어링이라고 판단되면 말씀하신 것처럼 Event 발행하면서 JPQL 로 Bookmark 카운트만 줄여도 괜찮을 것 같아요.

해당 방식으로 진행하도록 하겠습니다.

a 에서 조회한 topic 객체의 bookmarkCount 가 변경되지 않아, 해당 메서드에서 Topic 을 재 사용할 때 문제가 되는 것 뿐만 아니라, 변경감지로 인하여 감소시킨 Bookmark Count 가 원래대로 돌아오는 현상이 발생하기도 할까요?

JPQL로 작성된 메서드를 호출하게 되면, 변경감지 대상이 된 아이들(?)은 flush가 되게 됩니다.
이후에, 해당 메서드에 clearAutomatically 옵션을 주기 때문에, 영속성 컨텍스트를 비우게 되죠 !
그래서, 원래대로 돌아오는 현상은 발생하지 않는답니당 ~

[kpeel5839]

멋져부렁 쟈기