Step 10: 시나리오별 동시성 통합 테스트 작성 및 Chapter 2 회고 #26
Conversation
| @@ -86,6 +94,31 @@ public Reservation reserveConcertSeat(Long concertSeatId, Long userId) { | |||
| return concertQueryService.getReservation(new GetReservationByIdQuery(reservationId)); | |||
| } | |||
|
|
|||
| @Retryable( | |||
| retryFor = RuntimeException.class, | |||
There was a problem hiding this comment.
낙관적 락 버전 충돌시 ObjectOptimisticLockingFailureException 가 발생합니다.
하지만 ObjectOptimisticLockingFailureException의 패키지 경로를 보면 org.springframework.orm 패키지에 포함되어있는데 이러면 orm에 종속적인 에러지 않을까 라는 생각이 들었습니다.
그래서 도메인 계층에서 orm을 알고 있어야 할까에 의문이 들어서 RuntimeException 일 경우에 retry 하도록 지정했는데 조언 부탁드림다!
There was a problem hiding this comment.
백엔드를 하면서 orm을 사용하지 않고 데이터베이스의 테이블을 객체지향 페러다임에 맞게 바꿀 수 있는 방법이 있을까요?
제 개인적인 생각이지만, orm에 의존적이다 -> 의존적일 수 밖에 없다 라고 생각합니다.
| @Retryable( | ||
| retryFor = RuntimeException.class, | ||
| noRetryFor = CoreException.class, | ||
| backoff = @Backoff(50) | ||
| ) | ||
| @Transactional | ||
| public Reservation reserveConcertSeat(Long concertSeatId, Long userId) { |
There was a problem hiding this comment.
낙관적 락 버전 충돌시 retry한 이유는 재시도해서 이미 예약된 건이라는 exception을 throw하고 싶었습니다.
재시도를 하는 것이 많은 비용을 쓰지 않을까 고민이 들었고 락버전 충돌 exception일 경우 재시도하지 않고 예약 되었다는 exception으로 바꿔서 throw하는게 좋았을지 의문입니다.
There was a problem hiding this comment.
낙관적 lock에서는 버전이 이미 한 번 충돌했다는 것만으로 retry가 필요 없는 것 아닌가요?
There was a problem hiding this comment.
저라면 '락버전 충돌 exception일 경우 재시도하지 않고 예약 되었다는 exception으로 바꿔서 throw하는게 좋았을지' 말씀해주신 후자로 처리할 것 같습니다. 말씀해주신 방법이 있는데 굳이 retry를 해서 db에 요청을 보내는 io작업을 발생시키는게 맞을까? 라는 의문이 오히려 드는 것 같습니다.
요구사항
작업 내용
리뷰포인트