[🌱 JPA 방탈출 예약 대기] 티모 미션 제출합니다.

[Yoonhojoon]

체크 리스트

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

베이스 코드 선택 체크

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

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

단계별 도달 지점

1. JDBC 기반 저장소를 JPA 저장소로 전환했습니다.

   • Reservation, Theme, ThemeSlot, Time을 JPA Entity로 매핑했습니다.
   • ReservationStatusConverter를 추가해 상태 객체를 DB 문자열 컬럼과 연결했습니다.
   • 확정 예약 중복을 DB 레벨에서도 막기 위해 confirmed_theme_slot_id 생성 컬럼과 unique 제약을 사용했습니다.

2. JPA 전환 이후 예약 흐름의 동시성 지점을 정리했습니다.

   • 예약 생성/취소/변경 시 ThemeSlot 또는 Reservation을 비관적 락으로 조회하도록 했습니다.
   • 예약 변경처럼 두 슬롯을 동시에 다루는 흐름에서는 ID 순서대로 슬롯을 잠가 데드락 가능성을 줄였습니다.
   • 상태 변경은 기대 상태를 함께 확인해 이미 변경된 예약을 덮어쓰지 않도록 했습니다.

3. 예약 대기를 Reservation(PENDING)이 아니라 별도 Waiting 도메인으로 분리했습니다.

   • 대기 신청/취소 API를 /waitings로 분리했습니다.
   • 내 예약 조회에서 예약 목록과 대기 목록을 나누어 반환했습니다.
   • 확정 예약 취소/삭제/변경으로 슬롯이 비면 첫 번째 Waiting을 Reservation(CONFIRMED)으로 승격하고, 해당 Waiting은 삭제하도록 했습니다.

4. 어드민 대기 관리 API를 추가했습니다.

   • GET /admin/waitings로 전체 대기 목록을 순번과 함께 조회합니다.
   • DELETE /admin/waitings/{id}로 관리자가 소유자 검증 없이 대기를 취소할 수 있게 했습니다.

발행 SQL 발췌

확정 예약은 한 슬롯에 하나만 존재해야 하므로 생성 컬럼과 unique 제약을 사용했습니다.

confirmed_theme_slot_id BIGINT GENERATED ALWAYS AS (
    CASE WHEN status = 'CONFIRMED' THEN theme_slot_id ELSE NULL END
),

UNIQUE (confirmed_theme_slot_id)

취소/변경 대상 예약은 먼저 row lock을 잡고 처리합니다.

SELECT id
FROM reservation
WHERE id = :reservationId
FOR UPDATE

대기 순번은 저장하지 않고 조회 시 계산합니다.

SELECT new roomescape.domain.WaitingWithRank(
    w,
    (SELECT COUNT(w2) + 1
     FROM Waiting w2
     WHERE w2.theme = w.theme
     AND w2.date = w.date
     AND w2.time = w.time
     AND w2.id < w.id)
)
FROM Waiting w
WHERE w.memberName = :memberName
ORDER BY w.id

JPA dirty checking 관찰에서는 상태 변경 후 flush 시점에 다음 UPDATE가 발행되는 것을 확인했습니다.

update reservation
set name=?, status=?, theme_slot_id=?
where id=?

망설인 결정

첫 번째는 대기를 Reservation(PENDING)으로 유지할지, 별도 Waiting 테이블로 분리할지였습니다. 처음에는 예약 상태만으로 대기를 표현할 수 있다고 봤지만, 실제 예약과 대기는 소유하는 의미가 달랐습니다. 대기는 아직 슬롯을 점유하지 않고, 순번과 승격 대상이라는 성격이 더 강했습니다. 그래서 Waiting을 별도 도메인으로 분리하고, 승격 시 새 Reservation(CONFIRMED)을 만드는 방식으로 바꿨습니다.
두 번째는 예약 취소와 자동 승인을 하나의 트랜잭션으로 묶을지였습니다. 사용자의 직접 요청은 취소이고 자동 승인은 후속 처리로 볼 수도 있지만, 이번 구현에서는 슬롯 점유 상태의 일관성을 더 우선했습니다. 취소, 첫 대기 승격, 대기 삭제, 슬롯 해제가 함께 성공하거나 함께 롤백되도록 하나의 트랜잭션 안에 두었습니다.

흔들린 한 장면

가장 흔들렸던 지점은 확정 예약을 취소한 뒤 첫 대기 승격을 트랜잭션으로 묶는 작업이었습니다. 기존에는 당연히, 취소와 승격을 같이 일어나야 하는 상황이기 때문에 한 트랜잭션으로 묶는 것이 타당하다고 느껴졌습니다.