인프런 커뮤니티 질문&답변
작성한 질문수
TransactionalEventListener 관련 문의드리고자 글 남깁니다.
해결된 질문
작성
·
62
0
안녕하세요, 강사님 늘 강의 잘 듣고 있습니다, 감사합니다 !
다름이 아니고, @Transactional과 @TransactionalEventListener 설정 관련해 궁금한 사항이 있어서 문의드리게 되었습니다.
강의내용은 @Transactional, @TransactionalEventListener가 전역적으로 선언되었고 outbox 관련 로직만 존재하기 때문에 괜찮지만
제 업무환경에서는 @TrasnactionalEventListener가 사용되면 프로젝트의 모든 @Transactional으로 관련된 내용이 바인딩되기 때문에 이를 scope 별로 구분하는 방법이 필요해보였는데요.
따로 알아보았지만, payload(강의에서는 OutboxEvent) 를 통해 분기처리하는 방법만 보이다보니 혹시 관련하여 TrasnactionalEventListener 어노테이션 필드 혹은 커스텀 어노테이션만으로 구분할 수 있는 방법이 있을까요 ?
문의드리는 가장 큰 이유는 outbox 로직이 필요없는 DB처리에도 TrasnactionalEventListener이 우선은 호출되고 payload를 통해 early return 시키려고 하다보니, 불필요한 리소스 사용을 방지하고 싶어서 문의드리게 되었습니다.
답변 2
1
자기개발하고싶어요님, 안녕하세요!
payload(강의에서는 OutboxEvent) 를 통해 분기처리하는 방법만 보이다보니
제가 보기엔 이게 가장 깔끔하고 편할 것 같은데, 굳이 다른 방법을 찾으시는 이유가 있을까요?
파라미터 타입이 다르면 호출이 되지 않는데, 어떠한 부분에서 불필요한 리소스 사용이라고 느끼셨을까요?
다른 구현 방법으로는,
@TransactionalEventListener의 condition 필드를 사용해서 분기 조건을 만들 수도 있고,
단일 리스너에서 직접 분기 코드를 작성할 수도 있습니다.
직접 원하는 부분에만 커스텀 애노테이션을 만들어서 AOP를 적용시킬 수도 있고요.
다만, 그냥 파라미터 타입만 달리해서 구현을 하는게 가장 간단하고 편할 것 같네요!
0
말씀하신 것 처럼 payload를 통한 분기가 가장 간단해 보이기는 하지만, DB TPS가 높은 환경에서, 모든 트랜잭션 어노테이션에 대해 @TransactionalEventListener 가 동기적으로 호출된다는 부분이 마음에 걸려서 문의드리게 되었습니다. (리소스 상 큰 차이는 없겠지만요 .. !)
테스트를 해봐야 명확하겠지만, 아무래도 말씀해주신 커스텀 어노테이션을 통한 AOP가 가장 나을 것 같아보이기도 합니다.
감사합니다.
앗 제가 가장 간단하다고 말씀드린건, 리스너 메소드의 파라미터를 달리하는 것이었습니다.
물론, payload를 통한 분기도 비슷하게 간단하네요.
DB TPS가 높은 환경에서 호출이 우려된다는건 before commit 이벤트를 받는 리스너에 대한 이야기인가보군요. (그냥 트랜잭셔널 메소드 호출 TPS가 많다는 의미시려나요? 아무튼..!)
발행하는 이벤트 타입을 우려되는 리스너 메소드의 파라미터와 달리하면, 애초에 호출되지 않습니다.
만약 호출되는 상황이라고 하더라도, 블로킹되는 I/O 또는 오랜 시간 걸리는 작업을 포함해둔게 아니라면, 이 정도로는 문제되진 않을 것이고요.
정확히 어떤 상황을 생각하시는지는 모르겠으나, 우려할 정도로 문제될 것 같진 않습니다!
테스트로 잘 점검해 보시면 좋을듯 하네요!