[🌱 JPA 방탈출 예약 대기] 어셔(박진우) 미션 제출합니다.

[sinequanonn]

JPA 전환 및 예약 대기 기능

JdbcTemplate 기반 방탈출 예약 코드를 JPA로 전환하고, 그 위에 각 단계별 기능을 추가했다.

단계별 도달 지점

• 0단계: 브랜치 분리 및 기존 동작 확인 후 수정 방안 고민
• 1단계: 모든 도메인(Theme, ReservationTime, Reservation, Holiday) JpaEntity로 전환, ManyToOne 단방향 연관 관계 매핑, JpaRepository로 교체(Jdbc 잔재 제거하기), 동시성용 reservation_slot만 raw SQL 유지
• 2단계: GET /reservations-mine 내 예약 목록 조회 (메서드 이름 쿼리로)
• 3단계: 예약 대기 요청, 취소(/waitings), N번째 대기 표시, N+1 문제 해소
• 4단계: 관리자 대기 목록 조회, 취소, 예약 취소 시 자동 승격

발행 SQL 발췌

N번째 대기 - 서브쿼리와 fetch join 사용

select r.id, ..., t.*, rt.*,
  (select count(w.id) from reservation w
   where w.theme_id=t.id and w.time_id=rt.id
     and w.status='WAITING' and w.created_at < r.created_at)
from reservation r
join theme t on t.id=r.theme_id
join reservation_time rt on rt.id=r.time_id
where r.name=? order by r.id

• 순번을 인메모리로 계산하고 EAGER로 연관 로딩했을 때는 각 하나의 예약마다 Theme과 Time에 대한 정보를 얻기 위해 쿼리가 나갔다
• JPQL과 fetch join을 활용해서 한 방 쿼리로 N+1 문제가 발생하지 않게 했다.

망설인 결정

1. 자동 승인 트랜잭션 경계
   : 취소와 승격을 단일 @Transactional로 묶었다. "취소 성공, 승격 실패"를 허용하려면 커밋 후 이벤트로 분리해야 한다고 판단했다. 그러면 취소와 승격 사이에 동시성을 고려해야 할 게 많아졌다. 누가 실패 비용을 지는가를 따져보고 원자성을 선택했다.
2. JPQL fetch join vs @EntityGraph
   : 둘 다 연관을 한 쿼리로 당겨오지만, 표현력이 다르다. 단순한 연관만 함께 로딩하면 되는 조회는 메서드 이름 쿼리에 애노테이션을 붙여 처리하고, n번째 대기와 같이 서브쿼리로 순번을 계산해야 하는 (즉, 중간 결과를 투영해야하는 상황이 필요할 때)는 JPQL을 사용하는 방향으로 결정했다.

흔들린 한 장면

지연 로딩과 즉시 로딩을 제대로 이해하지 못하고 있었다. findByName 메서드 이름 쿼리를 쓸 때, EAGER면 즉시 로딩이니깐 JPA가 한 방 join 쿼리로 가져오는 줄 알았다. 하지만 로그를 보니깐 EAGER여도 예약을 먼저 조회하고 연관은 건마다 별도 SELECT가 나가는 것을 확인할 수 있었다. 알고보니 id로 조회(findById)할 때만 조인으로 한 번에 가져오고, id가 아닌 조회는 EAGER여도 연관마다 별도 쿼리가 나가 N+1이 될 수 있다는 것을 알게 되었다. 즉 즉시/지연은 언제 로딩하느냐에 포커스를 맞추고, 어떻게는 보장하지 않는다. 그래서 쿼리에서 한 번에 가져오려면 join fetch나 entityGraph를 직접 명시해야 한다는 점을 익혔다.