[🌱 JPA 방탈출 예약 대기] 피온(임현수) 미션 제출합니다.

[everypine]

단계별 도달 지점

• 0단계: everypine -> jpa로 브랜치 생성 및 체크아웃, 방탈출 미션 동작 확인
• 1단계: JdbcTemplate -> JPA 전환, 연관관계 매핑, 영속성 컨텍스트 관찰 및 신호 확인
• 2단계: 본인 예약 목록 조회 API를 요구사항에 맞게 수정 (메서드 이름 쿼리 사용)
• 3단계: 예약 대기 요청(예약 기능에 포함) 및 취소 (soft delete), 예약 목록 조회에 대기 예약도 포함, 예약 순번 표시 추가
• 4단계: 관리자 대기 목록 조회, 취소 기능 추가, 자동 방식의 예약 대기 승인 기능 추가

발행 SQL 발췌

1. IDENTITY strategy로 생성하는 @GeneratedValue

insert 
    into
        reservation
        (date_id, name, status, theme_id, time_id, waiting_order, id) 
    values
        (?, ?, ?, ?, ?, ?, default)

• JdbcTemplate: id가 담기지 않는 암묵적인 방식으로 삽입
• JPA: IDENTITY strategy에서는 id 생성을 DB에 위임, default는 Hibernate의 DB dialect에 따라 명시된 표현

2. 연관관계가 있는 엔티티의 조회

다음은 findById(reservationId).getTime().getStartAt()가 호출되었을 때 발행되는 SQL이다

select 
	r1_0.id, 
	r1_0.date_id, 
	r1_0.name, 
	r1_0.status, 
	r1_0.theme_id, 
	r1_0.time_id, 
	r1_0.waiting_order 
from 
	reservation r1_0 
where 
	r1_0.id=? 

select 
	rt1_0.id, 
	rt1_0.is_active, 
	rt1_0.start_at 
from 
	reservation_time rt1_0 
where 
	rt1_0.id=?

findById(...)까지는 외래키 컬럼인 time_id만 조회하고, 이후 LAZY 연관 관계의 실제 필드에 접근하면 추가 쿼리가 발생한다.

3. fetch join 쿼리

select
        r1_0.id, r1_0.date_id,
        d1_0.id, d1_0.date, d1_0.is_active,
        r1_0.member_id, r1_0.status, r1_0.theme_id,
        t1_0.id, t1_0.description, t1_0.is_active, t1_0.name, t1_0.thumbnail_url,
        r1_0.time_id,
        t2_0.id, t2_0.is_active, t2_0.start_at,
        r1_0.waiting_order 
    from
        reservation r1_0 
    left join
        member m1_0 
            on m1_0.id=r1_0.member_id 
    join
        reservation_date d1_0 
            on d1_0.id=r1_0.date_id 
    join
        theme t1_0 
            on t1_0.id=r1_0.theme_id 
    join
        reservation_time t2_0 
            on t2_0.id=r1_0.time_id 
    where
        m1_0.id=? 
    order by
        r1_0.id desc

다음 SQL은 아래 코드가 발행한 SQL문이다.

@EntityGraph(attributePaths = {"date", "time", "theme"})  
List<Reservation> findAllByMemberIdOrderByIdDesc(Long id);

• date, time, theme는 조회 시점에 함께 로딩되게끔 설정되었다.
• member는 attributePaths에 등록되지 않아 지연 로딩 대상이지만 where 조건절을 위해 join 연산이 실행되었다.

망설인 결정

1. 본인 예약 목록 조회(GET /reservations-mine) 쿼리 구성

• 선택지 A: 메서드 이름 쿼리 방식 사용
• 선택지 B: JPQL 방식 사용
• 나의 선택: B
• 이유: 단순 예약 목록만 조회한다면 findByMemberId를 사용하는 것만으로도 충분했을 것이다. 하지만 현재 구조에서는 예약이 대기 상태이면 순번 정보도 가지고 있으므로 메서드 이름 쿼리 방식만으로는 한계가 있었다. 결과적으로 JPQL를 사용하게 되었다.

2. 순번 정보가 없는 예약 목록 조회에서의 연관 엔티티 조회 방식

• 선택지 A: JPQL에 fetch join 명시
• 선택지 B: @EntityGraph 사용
• 나의 선택: B
• 이유: 선택지 A는 JPQL을 사용하는 전제가 있는데 순번 정보가 없는 예약 목록 조회는 복잡한 조건이 없어 메서드 이름 쿼리로도 충분하기에 고려를 하지 않았다. 또한, 선택지 B의 경우에는 어떤 연관 정보를 로딩할지 한눈에 볼 수 있는 장점도 있었다.

흔들린 한 장면

대기 예약 승인 로직은 기존에 이미 동시성을 충분히 고려하여 작성하였기에 Jdbc -> JPA 전환 과정에서도 크게 건들지 않아도 되겠다고 생각했었다. 그런데 JPA에서는 같은 id를 가진 엔티티의 재조회가 일어나면 db에서 가져오지 않고 1차 캐시에서 가져온다는 사실을 간과했다. 즉, 트랜잭션 중간에 DB 상태가 변경되었는지 확인하는 로직이 JPA 환경에서는 제대로 동작하지 않았다. 이를 위해 처음에 조회한 컨텍스트 내 reservation을 refresh하는 로직을 추가하여 재확인이 안되던 문제를 수정했다.