[🌱 JPA 방탈출 예약 대기] 코로구(구진) 미션 제출합니다.

[korogoo]

체크 리스트

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

베이스 코드 선택 체크

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

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

0단계 (JPA 인프라 세팅)

NESTED → REQUIRES_NEW

현재 applicationService 단에서 Transactional 을 붙이고 있고, 레포지토리랑 소통하는 service 단에서 트랜잭션을 전파받는 형태입니다. WaitingPromotionService는 예약 취소 후 대기 승격을 담당하는데, 승격 실패가 예약 취소 트랜잭션을 롤백시켜서는 안 됩니다.
이전에 NESTED를 사용한 이유도 이거 때문인데, JpaTransactionManager는 기본적으로 SavepointManager를 지원하지 않아서 NestedTransactionNotSupportedException이 발생했습니다.

JPA 에서 NESTED 를 사용하기에는 설정이 까다롭다고 판단하여 applicationService 에서 Transactional 을 제거하고, promotion 호출 부를 REQUIRES_NEW로 교체했습니다.

---

1단계 JPA 전환

JDBC vs JPA 코드 비교하기

JDBC에서는 반복되는 쿼리가 존재합니다.

• 모든 읽기 메서드에서 JOIN reservation_time, JOIN theme을 작성
• ResultSet에서 도메인 객체로 변환하는 mapToDomain() 또는 RowMapper를 클래스마다 구현
• Date.valueOf(localDate), rs.getDate(...).toLocalDate() 같은 타입 변환 코드

JPA에서는 @ManyToOne으로 관계를 한 번 선언하면 이후 조회에서 Hibernate가 JOIN 쿼리를 날립니다.
또한, 엔티티 객체로 소통할 수 있게 추상화 되어 있어 타입 변환도 없습니다.
대신 FetchType에 따라 로딩 전략을 선택해야 하고, LAZY를 쓰면 N+1 문제로 발생할 수 있어서 @EntityGraph나 fetch join 같은 해결 방법을 고민해야 합니다.

INSERT 로그 비교

같은 예약 생성 요청에서 발행되는 쿼리를 비교했습니다.

JDBC:

SELECT id, start_at FROM reservation_time WHERE id = ?
SELECT id, name, description, thumbnail_url FROM theme WHERE id = ?
SELECT COUNT(1) FROM waiting WHERE reservation_date = ? AND time_id = ? AND theme_id = ?
INSERT INTO reservation (name, date, time_id, theme_id) VALUES (?, ?, ?, ?)

JPA:
select rte1_0.id, rte1_0.start_at from reservation_time rte1_0 where rte1_0.id=?
select te1_0.id, te1_0.description, te1_0.name, te1_0.thumbnail_url from theme te1_0 where
te1_0.id=?
select we1_0.id from waiting we1_0
    where we1_0.reservation_date=? and we1_0.time_id=? and we1_0.theme_id=?
    fetch first ? rows only
insert into reservation (name, date, theme_id, time_id, id) values (?, ?, ?, ?, default)

id 처리 방식

JDBC는 id 컬럼을 직접 insert 하지 않고 AUTO_INCREMENT에 위임하고, JPA는 id 컬럼에 default를 전달합니다.

중복 체크 쿼리 차이

JDBC의 SELECT COUNT(1)은 전체를 세지만, JPA existsBy~ 메서드는 FETCH FIRST 1 ROWS ONLY로 변환되어 하나를 찾으면 즉시 중단합니다.

도메인 엔티티와 JPA 엔티티 분리

도메인 엔티티에 JPA 관련 코드를 제거하기 위해 JPA 엔티티를 별도로 두었습니다.
그리고 객체간 변환을 위해 Entity 내부에 toDomain() / from() 정적 변환 메서드를 구현했습니다.

---

2단계 내 예약 목록 조회

메서드 이름 쿼리를 JPQL로 전환

처음에는 메서드 이름 쿼리를 사용하려 했고, 현재 시간 이후의 예약만 필터링 이라는 조건을 구현하기 위해 date와 time.startAt 두 컬럼이 필요했습니다.

메서드 이름으로 구현했더니 아래와 같았습니다.

findByCustomerNameAndDateAfterOrCustomerNameAndDateAndTime_StartAtAfter(...)

메서드가 너무 길어서 가독성이 너무 떨어진다고 판단했고, 현재는 JPQL로 구현했습니다.

@Query("""
    SELECT r FROM ReservationEntity r
    WHERE r.customerName = :customerName
      AND (r.date > :date OR (r.date = :date AND r.time.startAt > :time))
    """)

단, JPQL은 문자열이라 컴파일 타임에 오류를 잡을 수 없고, 필드명이 바뀌면 런타임에서 터집니다.
또한 r.time.startAt처럼 연관 엔티티의 필드를 WHERE 조건에서 참조하면 Hibernate가 묵시적으로 INNER JOIN을 추가하는데, 이 JOIN은 코드에 명시되지 않기 때문에 실제 동작 방식을 알고있지 않으면 의도치 않은 결과를 반환받을 수 있습니다.

@EntityGraph로 N+1 방지

findById 쿼리는 다음과 같습니다.

select re1_0.id, re1_0.name, re1_0.date,
       t1_0.id, t1_0.description, t1_0.name, t1_0.thumbnail_url, re1_0.theme_id,
       t2_0.id, t2_0.start_at, re1_0.time_id
from reservation re1_0
left join theme t1_0 on t1_0.id=re1_0.theme_id
left join reservation_time t2_0 on t2_0.id=re1_0.time_id
where re1_0.id=?

@EntityGraph(attributePaths = {"time", "theme"})를 선언하면 이렇게 LEFT JOIN으로 한 번에 가져옵니다.
JDBC에서 findAll에 매번 JOIN을 직접 작성하던 것과 비교하면 훨씬 간단했습니다.

---

3단계 예약 대기 (대기 순번)

ROW_NUMBER() OVER (PARTITION BY ...) 윈도우 함수는 JPQL이 지원하지 않기 때문에 대기 순번 계산은 native query 를 사용했습니다.
처음엔 서비스 레이어에서 애플리케이션 레벨로 계산하는 방법도 고민했지만, 대기 수가 많아질수록 전체를 메모리에 올려 처리하는 게 부담스럽다고 판단했습니다.

---

4단계 예약 취소 시 자동 승격

예약 취소(cancelReservationByIdAndPromoteWaiting)에서 WaitingPromotionService.promoteBySlot()을 호출합니다.
승격 실패가 예약 취소를 롤백시키지 않도록 REQUIRES_NEW로 분리했고, 승격 중 발생하는 예외는 catch로 잡아서 log.error 로 기록하는 것으로 마무리했습니다.
만약 데이터 정합성 문제를 더 견고하게 잡고싶다면, 대기 승격을 이벤트 기반으로 아예 분리하고, 몇차례의 재시도 로직을 넣는 방법도 있습니다. 하지만, 이 부분은 미션 범위를 벗어난다고 생각하여 아직은 구현하지 않고 구상만 해두었습니다.