[🌱 JPA 방탈출 예약 대기] 이산(이채린) 미션 제출합니다.

[Rix01]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

베이스 코드 선택 체크

• 이전 미션의 내 코드에서 시작
• 이전 미션의 페어의 코드에서 시작

어떤 부분에 집중하여 리뷰해야 할까요?

단계별 도달 지점

• 1단계: JDBC → JPA 매핑 변환 완료. @Entity, @ManyToOne(fetch = LAZY), @JoinColumn 적용. 단방향 매핑 유지, cascade 미적용.
• 2단계: Member 도메인 추가. Reservation, WaitingReservation의 name(String) 필드를 Member 연관관계로 교체. GET /reservations-mine 엔드포인트 추가.
• 3단계: 예약 대기 기능 구현. N번째 대기 순번 계산은 윈도우 함수(row_number())가 필요해 Native Query 사용. 대기 승격 시 동시성 문제 해결을 위해 비관적 락(@Lock(PESSIMISTIC_WRITE)) 적용.
• 4단계: 예약 취소·수정 시 자동 승격 구현 완료.

---

발행 SQL 발췌

대기 순번 조회 (Native Query)

SELECT wr.id, row_number() OVER (
    PARTITION BY wr.date_id, wr.time_id, wr.theme_id
    ORDER BY wr.created_at ASC, wr.id ASC
) AS rank
FROM waiting_reservation wr
JOIN (
    SELECT date_id, time_id, theme_id
    FROM waiting_reservation
    WHERE member_id = :memberId
) slot ON wr.date_id = slot.date_id AND wr.time_id = slot.time_id AND wr.theme_id = slot.theme_id

슬롯 기준 가장 오래된 대기 조회 (JPQL + 비관적 락)

SELECT wr.*
FROM waiting_reservation wr
JOIN reservation_date d ON wr.date_id = d.id
JOIN reservation_time t ON wr.time_id = t.id
JOIN theme th ON wr.theme_id = th.id
WHERE wr.date_id = ? AND wr.time_id = ? AND wr.theme_id = ?
ORDER BY wr.created_at ASC, wr.id ASC
LIMIT 1
FOR UPDATE

---

망설인 결정

1. 단방향 매핑 유지
Reservation → Theme 등 모두 단방향으로 유지했다. 양방향으로 하면 Theme에서 List<Reservation>을 탐색할 수 있지만, 실제로 그 방향의 탐색이 필요한 경우가 없었고 무한 직렬화 위험도 있어 JPQL로 역방향 조회를 하는 쪽을 선택했다.

2. 동시성 처리 범위
time_id, date_id, theme_id를 Slot 도메인으로 묶으면 Slot 엔티티 자체에 락을 걸어 더 명확한 동시성 제어가 가능했을 것이다. 코드 변경 범위가 너무 커져 도입하지 못했고, 현재는 1순위 대기 조회 쿼리에 비관적 락을 걸어 임시방편으로 처리했다.

---

흔들린 한 장면

자동 승격 로직을 하나의 트랜잭션으로 묶는 게 맞는지 계속 흔들렸다. 결제 API 같은 외부 시스템이 껴들어오면 트랜잭션 안에서 처리하는 방식이 한계를 드러낸다는 걸 알면서도, 현재 요구사항 범위에서는 서비스 계층 한 메서드 안에 묶는 게 가장 단순하고 명확했다. 외부 API가 추가되는 시점에 도메인 이벤트 + 보상 트랜잭션으로 분리하는 게 맞다고 판단했다.

---