이벤트에서 트랜잭션을 분리할 때 어떤 어노테이션을 사용해야 할까?

[swonny]

이벤트에서 트랜잭션을 분리할 때 어떤 어노테이션을 사용해야 할까?

기존 디스커션(이벤트와 트랜잭션 관련)에서 추가적인 고민이 필요한 부분에 대한 추가 설명입니다.

기존 디스커션에서 가졌던 의문점들이 있어서 수정하기보단 2편 느낌으로 새로 작성해봤습니다!

문제 상황

• 메시지 알림 실패로 인한 메시지 전송 실패
• 메시지 전송 트랜잭션이 메시지 알림 기능의 영향을 받는 것이 부자연스럽다고 판단해 트랜잭션 분리 시도

예외가 발생해서 try-catch로 잡아주었는데도 롤백되는 문제가 발생했습니다.

1. 원래는 messageService.create() → notificationService.send()를 호출
2. messageService.create() 에서 notificationService.send() 호출 시 try-catch를 통해 예외를 잡아주고 있음.
3. NullPointerException은 RuntimeException이다. 따라서 RuntimeException이기 때문에 발생하는 곳에서 예외를 잡아주지 않았기 때문에 rollback 마크를 했기 때문에 롤백

첫 번째 시도

@EventListener
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void sendNotification(final NotificationEvent notificationEvent) {
    // 이벤트 처리 생략
}

단순히 트랜잭션 전파 옵션을 사용해 트랜잭션을 분리해주는 것입니다.

트랜잭션을 분리해준다면 새로운 트랜잭션에서 예외가 발생해 트랜잭션이 롤백되더라도 외부 트랜잭션에는 영향을 미치지 않아야 한다고 생각했습니다. 하지만 트랜잭션 전파와 트랜잭션 예외 전파는 다르다는 것을 인지하지 못했고, 따라서 새로운 트랜잭션에서 예외가 발생한다면 기존 트랜잭션에도 예외가 전파됩니다. 따라서 발생하는 예외를 try-catch로 잡아주어야 했습니다.

(실습 자료 참고)

따라서 이벤트 리스너에서 try-catch문을 추가해주게 되었습니다.

이때 이벤트를 발행한 메서드에서 예외 핸들링을 해주지 않은 이유는 예외를 핸들링해주는 역할은 이벤트 리스너에게 종속된다고 판단했기 때문입니다. 관심사 분리를 위해 이벤트 사용한 만큼 이벤트를 발행하는 쪽에서는 ‘이벤트 발행’까지만 책임을 가지고, 이후에 발생하는 일들에 대해서는 트랜잭션이 롤백되거나 심지어 예외가 발생하는 것조차 몰라야 한다고 생각했습니다. 그리고 이것이 이벤트를 사용하는 목적이라고 생각했기 때문입니다.

결론

• 트랜잭션 분리를 위해 트랜잭션 전파 옵션 중 Propagation.REQUIRES_NEW 사용
• 예외 전파와 트랜잭션 전파는 동일하지 않은 개념으로, 예외 전파를 막기 위해 이벤트 리스너에서 예외 핸들링

두 번째 시도

@TransactionalEventListener
public void sendNotification(final NotificationEvent notificationEvent) {
    // 이벤트 처리 생략
}

지토의 질문으로 인해 트랜잭션 커밋 시점에 대해 공부하게 되었습니다.

해당 이벤트리스너 메서드는 Bid의 내용이 DB에 저장된 이후에 동작해야 할 것 같은데, 이에 대해서 고려했는지 궁금합니다!
위에 쪽지같은 경우는 그냥 씹혔나보다 싶은 느낌으로 가볍게 넘길 수도 있겠지만, 해당 Bid는 입찰이라는 중요한 도메인이기 때문에 꼭 확인하고 싶어서 필수로 두었습니다

@EventListener를 사용할 경우 이벤트를 발행한 트랜잭션의 커밋 시점은 발행한 이벤트가 모두 종료된 이후입니다. 알림 기능에서는 추가적인 DB 쓰기 작업이 발생하지 않음에도 불구하고 메시지 저장 트랜잭션은 알림이 API 호출로 인해 네트워크 요청이 발생하고 종료될 때까지 커밋하지 못한 상태로 대기해야 했습니다.

이때 두 가지 문제점이 있습니다.

1. 메시지 전송 트랜잭션의 커밋 이후 알림 전송한다는 로직이 보장되지 않습니다.

   메시지 전송 트랜잭션이 알림 전송이 종료될 때까지 기다린 이후에 커밋됩니다. 따라서 알림 전송이 발생한 이후에 예기치 못한 에러로 메시지 전송 트랜잭션이 롤백된다고 해도 이미 사용자에게는 알림 전송이 완료된 상태가 됩니다. 즉, DB에 저장된 데이터와 사용자가 전달받게 될 데이터의 정합성이 깨지는 것입니다.

   지토가 남겨주신 의견처럼 메시지 알림은 롤백된 데이터에 대한 알림이 가더라도 사용자에게 의문을 불러일으킬 뿐 금전적인 문제로 이어지지는 않습니다. 하지만 입찰의 경우는 다릅니다. 상위 입찰자가 발생했을 때 사용자는 상위 입찰자 발생 알림을 받게됩니다. 상위 입찰자가 발생했다고 생각해 추가적인 입찰을 위해 경매글을 조회했지만 상위 입찰자가 존재하지 않는 경우에는 금전적인 문제로 이어져 메시지보다 더 비즈니스적으로 심각한 문제가 될 수 있습니다.
   따라서 입찰 생성 트랜잭션이 정상적으로 커밋이 완료된 이후에 알림을 전송할 수 있도록 기존 커밋을 보장해야 합니다.

2. 불필요하게 트랜잭션이 길어집니다.

   앞서 언급한 것처럼 이벤트를 발행한 트랜잭션이 커밋되는 시점은 알림 기능이 종료된 이후입니다. 이때 알림 기능은 네트워크 통신이 발생하는 로직까지 포함하고 있고, 메시지 전송 트랜잭션은 커밋되기까지 그만큼의 시간이 소요되는 것이기 때문에 불필요하게 트랜잭션을 길게 유지하게 되어 비효율적인 트랜잭션이 유지됩니다.

해결 방법

@TransactionalEventListener 어노테이션을 사용합니다. 해당 어노테이션의 실행 시점 기본값은 AFTER_COMMIT 입니다. 즉, 이벤트 리스너가 실행되는 시점은 기존 트랜잭션인 메시지 전송 트랜잭션이 커밋된 이후라는 의미입니다. 따라서 이벤트 리스너에서 수행되는 기능에서 예외가 발생하더라도 이미 커밋된 트랜잭션은 롤백되지 않기 때문에 메시지 전송 기능 트랜잭션에서 알림 전송 기능을 완전히 분리할 수 있게 되는 것입니다.

다른 말로 @TransactionalEventListener 어노테이션만으로 메시지 전송 기능 트랜잭션에서 알림 전송 기능을 완전히 분리할 수 있게 되었기 때문에 트랜잭션 분리를 위해 사용했던 트랜잭션 전파 옵션 Propagation.REQUIRES_NEW 는 더이상 불필요하게 됩니다.

여기서 헷갈리지 않아야 하는 점은, @TransactionalEventListener 를 사용했을 때 트랜잭션이 커밋되는 것이지 트랜잭션이 완전히 종료되는 것은 아닙니다. 따라서 기존 트랜잭션에서 사용한 커넥션으로 DB 조회 작업은 여전히 가능합니다.

주의할 점

저희 서비스에서는 현재 알림 로그를 저장하지 않고 있습니다. 즉, 이벤트 리스너에서 호출한 서비스 트랜잭션에서 DB 쓰기 작업이 발생하지 않습니다. 그런데 만약 @TransactionalEventListener으로 기존 트랜잭션의 커밋 이후 쓰기 작업이 발생하는 트랜잭션을 생성했을 때 생성한 트랜잭션의 전파 속성이 REQUIRED라면 생성한 트랜잭션은 정상적으로 커밋되지 않습니다.

그 이유는 이벤트 리스너에서 사용하는 트랜잭션은 REQUIRED 옵션으로 인해 기존 트랜잭션에 참여하게 되기 때문입니다. 그런데 한 번 커밋된 트랜잭션은 이후에 어떤 일이 발생하더라도 롤백되거나 다시 커밋되지 않습니다. 그 이유는 트랜잭션 격리 수준을 유지하기 위해 한 번 커밋된 트랜잭션은 DB에 영구적으로 저장되어야 하기 때문이라고 합니다. (이 부분은 조금 더 근거가 필요할 것 같긴한데.. 우선 현재 내용에선 이정도로도 충분할 것 같아요!)

기존 트랜잭션이 커밋된 이후에 실행된다는 점에서 이후 로직과 독립적으로 트랜잭션 커밋이 충분히 보장되지만, 다른 말로 하면 트랜잭션이 종료되었음을 의미합니다. DB 읽기 작업에서는 커밋을 하지 않아도 되기 때문에 종료된 기존 커넥션을 조회 작업에서 사용할 수 있지만, 쓰기 작업은 커밋이 필요하기 때문에 기존에 사용하던 커넥션 사용이 불가능해집니다. 따라서 이후 DB 쓰기 작업을 위해 트랜잭션 커밋이 필요하다면 새로운 트랜잭션을 열어주어야 합니다.

결론적으로 @TransactionalEventListener를 사용한 경우, 이벤트 리스너에서 추가적인 쓰기 작업이 발생한 경우 트랜잭션을 분리해주어야 하고, 트랜잭션 분리를 위해 Propagation.REQUIRES_NEW 옵션을 사용하면 되는 것입니다!

(질문.. 영속성컨텍스트에 대해 잘 아시는분..)그런데 이때 주의해야할 점이 있습니다. 새로운 트랜잭션을 열어주어 영속성 컨텍스트가 달라지더라도 기존 트랜잭션을 커밋했다는 점에서 새로운 트랜잭션에서 기존 트랜잭션을 확인할 수 있을 것이라고 생각했는데, 새로운 트랜잭션을 열어준다는 점에서 영속성 컨텍스트가 달라지기 때문에 기존 트랜잭션에서 커밋한 내역을 볼 수 없게 된다고 합니다.

따라서 영속성 컨텍스트가 달라져 기존 커밋 내역을 확인할 수 없게 되어 발생할 수 있는 문제점들을 잘 고려해야합니다. 대표적으로 트랜잭션 분리로 인해 테스트가 깨졌던 사례가 있습니다.

아무튼! 이 부분은 저희 프로젝트에는 해당되지 않는 부분이지만, 추후 이벤트 리스너를 사용해 또다른 쓰기 작업을 진행하게 될 때 고려하면 좋을 것 같습니다.

세 번째 시도

@Async
@TransactionalEventListener
public void sendNotification(final NotificationEvent notificationEvent) {
    // 이벤트 처리 생략
}

이건 두 번째 시도의 주의점과 관련된 부분이고, 프로젝트와는 관련이 없습니다. @TransactionalEventListener 에 대해 공부하다 알게 된 내용이라 공유합니다.

@TransactionalEventListener 또는 @EventListener 를 사용하고 추가적인 쓰기 작업을 위해 Propagation.REQUIRES_NEW 옵션을 지정할 경우 데드락 문제가 발생할 수 있습니다.

트랜잭션 전파 옵션으로 트랜잭션을 분리한 경우, 트랜잭션이 물리적으로 분리된 것이 아닌 논리적으로 분리된 것입니다. 트랜잭션이 물리적으로 분리되는 것은 트랜잭션의 분리가 곧 스레드의 분리가 되는 것을 의미하고, 트랜잭션이 논리적으로 분리되었다는 것은 새로운 트랜잭션이 생성될 때 새로운 스레드가 생성되는 것이 아닌 새로운 커넥션을 점유하게 되는 것입니다. 즉, 하나의 스레드에서 두 개의 커넥션을 점유하게 되는 것입니다.

이때 데드락이 발생할 수 있습니다. 커넥션 풀에 저장된 커넥션의 개수가 5개라고 가정해봅시다. 이때 메시지 전송 트랜잭션을 위해 5개의 스레드가 동시에 접근해 커넥션을 각 1개씩 점유하게 됩니다. 그리고 이벤트를 발행해 Propagation.REQUIRES_NEW 옵션에 의해 논리적인 트랜잭션이 생성되고, 이를 위해 새로운 커넥션을 가져오려고 시도합니다. 하지만 남아있는 커넥션이 존재하지 않아 5개의 트랜잭션이 모두 다른 트랜잭션이 종료된 이후 커넥션이 반납되기를 기다리다 데드락이 발생하게 됩니다.

이처럼 Propagation.REQUIRES_NEW 옵션을 사용해 새로운 트랜잭션을 생성하는 방식은 하나의 스레드에서 두 개의 커넥션을 점유하게 되어 데드락으로 이어질 수 있다는 단점이 있습니다.

@TransactionalEventListener 또는 @EventListener 모두 이벤트를 수행하는 동안 이벤트를 호출한 쪽의 트랜잭션이 유지되기 때문입니다. (앞서 언급한 것처럼 @TransactionalEventListener 을 사용하더라도 트랜잭션 커밋이 완료될 뿐이지 트랜잭션은 유지됩니다.)

해결 방법

이를 해결하기 위해 @Async 를 사용할 수 있습니다. @Async 는 물리적으로 트랜잭션을 분리해버리기 때문에 새로운 스레드에 의해 커넥션을 점유하게 됩니다. 따라서 기존 트랜잭션이 새로운 트랜잭션의 종료시점까지 기다릴 필요가 없어지고, 따라서 기존 트랜잭션 하나만 종료되어 커넥션을 반납한다면 새로운 트랜잭션은 기존 트랜잭션이 커넥션을 반납할 때까지 기다렸다 커넥션을 점유하면 되는 것입니다. 따라서 데드락 발생을 피할 수 있게 됩니다.

이때 동기적으로 수행되어야 하는 로직의 경우에는 @TransactionalEventListener 를 사용해 기존 트랜잭션이 커밋된 이후 새로운 트랜잭션을 생성할 수 있도록 해야 합니다. (이 부분은 테스트 필요 @TransactionalEventListener 와 @Async 를 함께 사용한 경우 진짜 커밋될 때까지 기다리는지 테스트를 해봐야 할 것 같아요)

[apptie]

잘 읽었습니다 고생하셨습니다
하나 헷갈리는 부분이 있는데

그런데 이때 이때 주의해야할 점이 있습니다. 새로운 트랜잭션을 열어주어 영속성 컨텍스트가 달라지더라도 기존 트랜잭션을 커밋했다는 점에서 새로운 트랜잭션에서 기존 트랜잭션을 확인할 수 있을 것이라고 생각했는데, 새로운 트랜잭션을 열어준다는 점에서 영속성 컨텍스트가 달라지기 때문에 기존 트랜잭션에서 커밋한 내역을 볼 수 없게 된다고 합니다.
-> 요거는 영속성 컨텍스트 1차 캐시에서 기존 트랜잭션에서 커밋한 내역을 볼 수 없다고 말씀하신건가요? 아니면 DB에서 조회하더라도 기존 트랜잭션에서 커밋한 내역을 볼 수 없다고 말씀하신건가요?

[swonny]

저는 DB 조회할 때로 생각했습니다.
같은 트랜잭션 내에 있으면 같은 영속성 컨텍스트를 공유하고 있으니 커밋한 이후에도 조회가 가능했지만, 트랜잭션이 새로 생성되어 분리된다면 영속성 컨텍스트가 달라지기 때문에 새로운 트랜잭션에서는 기존 트랜잭션에서 저장한 데이터를 조회할 수 없다는 의미로 작성했습니다.

예를 들어 기존 트랜잭션에서 회원을 저장하고 새로운 트랜잭션에서 DB에서 회원을 조회해 정보를 수정하는 작업을 수행하고자 한다면 회원 정보 조회에 실패하게 되는 상황이 있을 것 같은데, 더 좋은 예시가 떠오르지 않네요.......

[apptie]

기존 트랜잭션이 커밋되었다는 것은 트랜잭션 리소스가 그대로 유지되는 것과는 상관 없이 DB에 변경 사항이 반영되었다는 의미라고 이해했는데, 대충 다음과 같은 상황이라고 생각했습니다

1. A 트랜잭션에서 데이터를 변경하고 commit
2. @TransactionEventListener + Propagation.REQUIRES_NEW를 통해 B 트랜잭션이 (논리적으로) 새로 생성

위와 같은 상황에서 트랜잭션이 새로 생성되어 분리된다면 영속성 컨텍스트가 달라지기 때문에 새로운 트랜잭션에서는 기존 트랜잭션에서 저장한 데이터를 조회할 수 없다는 의미로 작성했습니다.라고 말씀해주신 부분이 잘 이해가 되지 않습니다

저는 언급해주신 영속성 컨텍스트를 JPA의 영속성 컨텍스트로 이해하고 있는데, 1차 캐시에 없다면 DB에서 쿼리를 날려서 조회하니 영속성 컨텍스트의 여부와는 상관 없이 동작하게 된다고 생각해서 뭔가 혼란스럽습니다

정답을 알려주세요

[swonny]

저도 점점 생각하다보니 너무너무 헷갈려요...

그런데 제가 이해한 내용은

말씀해주신 것처럼 커밋이 완료되기 때문에 @TransactionEventListener + Propagation.REQUIRES_NEW를 통해 B 트랜잭션을 논리적으로 새로 생성한다면 새로 생성한 트랜잭션에서는 DB 조회가 가능하지만, 영속성 컨텍스트가 달라진다는 점이 주의해야 할 점이라고 생각했던 것 같습니다.

뭔가 오개념이 있는 것 같아서... 이 부분 주말까지 최대한 다시 수정해볼게요 🥹 우선 지토가 헷갈리실 것 같아서 저의 글을 너무 깊게 고민하지는 말아주세요.....

[swonny]

안녕하세요 지토?
제가 공부를 하다보니 정말 너무 깊은 곳까지 빨려들어가버려서 생각보다 오래 걸렸지만 드디어 제대로된 설명을 드릴 수 있을 것 같아요 ㅎㅎ..

우선 글에 몇 가지 오개념이 있었어요!

저의 업보를 청산해보도록 하겠습니다....

그런데 이때 이때 주의해야할 점이 있습니다. 새로운 트랜잭션을 열어주어 영속성 컨텍스트가 달라지더라도 기존 트랜잭션을 커밋했다는 점에서 새로운 트랜잭션에서 기존 트랜잭션을 확인할 수 있을 것이라고 생각했는데, 새로운 트랜잭션을 열어준다는 점에서 영속성 컨텍스트가 달라지기 때문에 기존 트랜잭션에서 커밋한 내역을 볼 수 없게 된다고 합니다.

새로운 트랜잭션을 생성하기 때문에 새로운 영속성 컨텍스트가 생성되는 것은 맞지만, 영속성 컨텍스트가 달라지더라도 DB에 커밋한 내역은 확인할 수 있습니다.

테스트 해본 결과, @TransactionalEventListener를 사용하고 REQUIRES_NEW 전파 속성을 사용한 경우에 이벤트 리스너에서 기존 트랜잭션에서 커밋한 내용을 조회할 수 있었습니다. 지토가 말씀해주신 것처럼 이벤트 리스너를 실행하는 시점은 이미 DB에 커밋이 완료된 상태이기 때문입니다.

조회만 가능했던 이유는 @TransactionalEventListener의 실행 시점 때문이었습니다. AFTER_COMMIT 속성으로 인해 @TransactionalEventListener의 실행 시점은 기존 트랜잭션이 DB에 커밋이 완료된 이후, 그리고 connection을 반환하기 이전이 됩니다. 그런데 아시다시피 논리 트랜잭션은 커밋이 되더라도 실제로 DB에 커밋되는 것은 아니고, 물리 트랜잭션이 커밋될 때 물리 트랜잭션에 묶인 논리 트랜잭션이 한 번에 같이 커밋이 됩니다.

원래 REQUIRED 트랜잭션의 동작 순서는 다음과 같습니다.

1. 물리 트랜잭션이 connection을 가져온다.
2. �connection을 가져온 트랜잭션에서 REQUIRED 트랜잭션 메서드를 호출한다.
3. 이후 물리 트랜잭션에 참여하는 모든 논리 트랜잭션 메서드가 커밋하여 영속성 컨텍스트에 변경 내용을 저장한다.
4. 모든 논리 트랜잭션이 정상적으로 커밋 되었다면 다시 connection을 가져왔던 트랜잭션으로 돌아가 실제 DB에 커밋한다.

그런데 @TransactionalEventListener에는 AFTER_COMMIT이 적용되면서 1번이 수행된 이후 논리 트랜잭션의 커밋 여부와는 상관 없이 바로 4번 DB에 커밋하는 로직을 수행해버리는 것입니다. 그러다보니 더이상 논리 트랜잭션에서 변경한 내역을 DB에 반영할 수 있는 코드가 남아있지 않아 DB 쓰기 작업이 불가능했던 것이었습니다!

그런데 앞서 말씀드린 것처럼 @TransactionalEventListener의 실행 시점은 기존 트랜잭션이 DB에 커밋이 완료된 이후, 그리고 connection을 반환하기 이전인데요! 커밋은 완료했지만 아직 connection을 반납은 실행되지 않았기 때문에 동일한 connection으로 조회가 가능했던 것입니다!

이 부분을 잘 설명하기가 참 어렵네요.. 혹시 이해가 안 되는 부분이 있으면 또 질문해주세요 지토!

그리고 글은 수정하려다가 어쩌다보니 전부 갈아엎게되었는데요.. 오개념이 있는 이 전체를 제가 새로 작성한 글로 덮어씌우는 게 나을까요? 아니면 새로운 글을 하나 또 만드는 게 좋을까요?

[apptie]

감사합니다 메리
속이 편안해졌어요
글은 저는 새로 하나 더 추가하는게 더 좋지 않을까 생각합니다
이번 글을 통해서 어떤 부분이 헷갈릴 수 있는지 알 수 있다고 생각해서 그렇습니다

[swonny]

해당 내용에 대해 더 더 자세히 다룬 메리의 첫 블로그 글이 있습니다!
우선 링크를 걸어두고, 디스커션에 또 올리도록 하겠습니다 😀

https://wonny-seung.tistory.com/2