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

[nn98]

단계별 도달 지점

0단계

• 정상 동작 / 테스트 통과 / 특이한 구조지만 설명 가능
• 이미 객체 기반 참조라 유지 / 참조 관계 역전 (예약/대기와 세션의 참조 관계) 시도

1단계

• 전체 Repository 전환
• 예약 생성을 위해 필요한 테마, 시간대를 id 기반으로 잘 조회해서 넣어줌
• findById... 실행시 select 2번 발생
• 영속성 컨텍스트 관찰 AI 로 테스트코드 짜서 돌렸는데 뭔가 복잡하게 나옴

2단계

• 목록 조회 네임쿼리 vs JPQL

현재 인증/인가가 구현되지 않은 코드이므로 MemberId 가 아닌 name 으로 식별 가능.

답변

메서드 이름 쿼리가 떠오름. 기본적으로 해당 엔티티의 필드로 존재하는 컬럼값에 대한 조회는
메서드 이름 쿼리 작성만으로 자동 구현되기 때문

• 선택

본인(의 이름)의 예약 목록 조회

네임쿼리.

다만 이번 단계에서 실험하고자 했던 내용을 충족하기 위해선
조회 조건이 사용자인게 중요한 게 아니라
1:N 구조에서 1 에 해당하는 엔티티의 ID로 N 에 해당하는 엔티티들을 조회하는?
조회 조건을 걸 때, 메서드 이름 쿼리와 JPQL 중
무엇을 택하고 그 이유와 한계가 무엇일지를 확인하는 것이라 생각해
세션id로 걸려있는 대기들을 조회하는 실험으로 변경

특정 세션(의 id)의 대기 목록 조회

네임쿼리.

JPA는 연관(의존/참조관계?) 엔티티의 필드까지 경로 탐색 가능.
메서드 이름에 해당 필드(sessionId)가 없더라도 자동으로 적절하게(session.id) 경로를 해석하기에.

생성되는 쿼리는 SELECT w FROM Waiting w WHERE w.session.id = :sessionId

• 한계

복합 / 중첩 쿼리 활용 제한.
복합적인 조건들이나 파라미터로 시그니처가 길어지면 가독성이 급격하게 저하됨

집계함수/그루핑/서브쿼리 불가.

• 명확히 인지하진 못한 내용
  JOIN FETCH 제어 불가
  위에서 선택한 네임쿼리로 조회한 대기들에 포함된 Session 에 접근할 때.
  Session 이 Lazy loading 이기에 접근할 때 마다 추가로 SELECT 발생. ==> N+1 문제.

3단계

• 자기 진단

처음엔 공유되는 필드가 많기에 상태만 주가해 주면 되지 않을까 생각했지만 
대기는 순번이라는 비즈니스 요구사항이 있고, 
이를 구현하기 위해 created_at 으로 순번을 계산하는 구조를 생각. 
이 구조에서 계산된 순번을 필요로 하는 것은 `예약` 이 아닌 `대기` 이기에 
예약과 대기가 목적과 책임과 역할이 다른 엔티티라 생각하고, 분리해서 별도 엔티티로 설계. 

• JPQL이 발행하는 SQL

@formula 로 우회해버리긴 했는데 여튼 나오는 결과는 동일

    @Formula("(SELECT COUNT(*) FROM waiting w2 WHERE w2.session_id = session_id AND w2.id <= id)")
    private Integer waitingNumber;

SELECT
    w.id,
    w.name,
    w.session_id,
    (SELECT COUNT(*) FROM waiting w2
     WHERE w2.session_id = w.session_id
     AND w2.id <= w.id) AS waitingNumber   ← 로 waitingNumber 계산
FROM waiting w
WHERE w.session_id = ?
ORDER BY w.id ASC 

• 네임쿼리의 한계

네임쿼리로는 표현할 수 없는 서브쿼리 등의 쿼리가 존재

4단계

발행 SQL 발췌

• findById(reservationId).getTime().getStartAt()이 발행하는 SQL

Hibernate: 
    select
        s1_0.id,
        s1_0.date,
        s1_0.theme_id,
        s1_0.time_id 
    from
        session s1_0 
    where
        s1_0.id=?
Hibernate: 
    select
        ts1_0.id,
        ts1_0.start_at 
    from
        time_slot ts1_0 
    where
        ts1_0.id=?

• JPQL이 발행하는 SQL

SELECT
    w.id,
    w.name,
    w.session_id,
    (SELECT COUNT(*) FROM waiting w2
     WHERE w2.session_id = w.session_id
     AND w2.id <= w.id) AS waitingNumber   ← 로 waitingNumber 계산
FROM waiting w
WHERE w.session_id = ?
ORDER BY w.id ASC 

망설인 결정 1~2개

이미 만들어진 구조로 해결되는 부분도, 생략 가능한 부분도 많았다 보니
어떤식으로 실험하고 JPA 학습을 진행해야 할까 싶었던 부분들?

• memberId 로 조회하는 로직을 뭘로 동일하게 실험할 것인가
• @Formula 로 대체한 부분을 JPQL 로 변경? 하이버네이트 동일한데?

흔들린 한 장면.

JPA 영속성 컨텍스트 관찰 및 신호 캡처.
도저히 실험할 엄두 안나서 AI 돌려서 테스트.

JPA 영속성 컨텍스트

JPA 영속성 컨텍스트 핵심 동작 정리

프로젝트: spring-roomescape-waiting (JPA 마이그레이션 이후 관찰 기록)

---

영속성 컨텍스트란

@Transactional 범위 안에서 JPA가 엔티티를 관리하는 1차 저장소.
DB와 애플리케이션 사이의 버퍼 역할을 하며, 트랜잭션이 닫히면 함께 소멸된다.

@Transactional 범위 안
┌─────────────────────────────┐
│  영속성 컨텍스트 (1차 캐시)     │
│  ┌──────────────────────┐  │
│  │ Session#1  id=1      │  │
│  │ Waiting#1  id=1      │  │
│  └──────────────────────┘  │
│          ↕ flush           │
│     H2 DATABASE            │
└─────────────────────────────┘

@Transactional 범위 밖
┌─────────────────────────────┐
│  영속성 컨텍스트 (닫힘)         │
│  ┌──────────────────────┐  │
│  │ TimeSlot 프록시 (미초기화)│  │
│  │  → getStartAt() 호출 시 │  │
│  │  LazyInitializationEx │  │
│  └──────────────────────┘  │
└─────────────────────────────┘

---

① 더티 체킹 (Dirty Checking)

현상: save() 없이 필드만 수정해도 트랜잭션 커밋 시 UPDATE 자동 발행

원리: 엔티티를 로드할 때 Hibernate가 그 시점의 필드값을 스냅샷으로 저장한다.
flush/commit 시 스냅샷과 현재 상태를 비교해 변경이 있으면 UPDATE를 자동 발행한다.

// save() 호출 없음
Session managed = em.find(Session.class, 1L);
managed.

setDate(LocalDate.now().

plusDays(99));  // 필드만 변경
        em.

flush();  // → UPDATE session SET date=? WHERE id=?

콘솔 출력:

update session
set date     = ?,
    theme_id = ?,
    time_id  = ?
where id = ?
-- save() 호출 없었지만 flush 시 자동 발행

---

② 1차 캐시

현상: 같은 트랜잭션에서 findById 두 번 호출 → SELECT 1회만 발행, 동일 인스턴스 반환

Session a = repo.findById(1L);  // SELECT 발행
Session b = repo.findById(1L);  // SQL 없음 (캐시 적중)

assert a ==b;  // true — 동일 인스턴스

콘솔 출력:

select s1_0.id, s1_0.date, s1_0.theme_id, s1_0.time_id
from session s1_0
where s1_0.id = 1
-- 두 번째 호출은 SQL 미발행

주의: 같은 트랜잭션(영속성 컨텍스트) 안에서만 유효.
em.clear() 또는 트랜잭션 경계를 넘으면 캐시 소멸.

---

③ 쓰기 지연 (Write-Behind)

현상: save() 시점에 INSERT가 즉시 발행되지 않고 flush/commit까지 지연될 수 있음

전략별 차이:

전략	INSERT 발행 시점	이유
IDENTITY (현재)	save() 즉시	DB가 id를 생성해야 하므로 지연 불가
SEQUENCE	flush/commit 시	시퀀스로 id를 미리 채번해 버퍼에 적재 가능

// IDENTITY 전략 (현재 프로젝트)
Reservation saved = repo.save(Reservation.transientOf("브라운", session));
// ↑ 여기서 즉시 INSERT 발행 (id가 필요하므로)
System.out.

println(saved.getId());  // null 아님

// SEQUENCE 전략이었다면
// save() 시점 → 버퍼에 적재 (INSERT 미발행)
// em.flush() 또는 commit 시점 → INSERT 일괄 발행

---

④ flush 시점

현상: flush()를 명시 호출하지 않아도 특정 시점에 자동으로 영속성 컨텍스트 → DB 동기화

자동 flush 발생 조건 3가지:

1. JPQL / Native Query 실행 직전 (FlushMode.AUTO 기본값)
2. 트랜잭션 커밋 시 (@Transactional 메서드 정상 종료)
3. em.flush() 명시 호출 (커밋 없이 DB에만 반영, 롤백 가능)

em.persist(waiting);  // 1차 캐시에만 존재

// JPQL 실행 직전 자동 flush
Long count = em.createQuery("SELECT COUNT(w) FROM Waiting w", Long.class)
        .getSingleResult();
// → persist한 데이터가 COUNT에 반영됨

콘솔 출력:

insert into waiting (name, session_id)
values (?, ?) ← 자동 flush
select count(w1_0.id)
from waiting w1_0 ← JPQL

---

⑤ fetch 기본값

현상: @ManyToOne(fetch = LAZY) 명시 → Session 로드 시 TimeSlot은 프록시로 대기

JPA 표준 기본값:

• @ManyToOne, @OneToOne → EAGER (기본)
• @OneToMany, @ManyToMany → LAZY (기본)

현재 프로젝트: 명시적으로 FetchType.LAZY 오버라이드

// Session.java
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "time_id")
private TimeSlot timeSlot;  // 로드 시 프록시 객체

콘솔 출력:

-- sessionRepo.findById(1L) 호출 시
select s1_0.id, s1_0.date, s1_0.theme_id, s1_0.time_id
from session s1_0
where s1_0.id = 1
-- time_slot JOIN 없음 ← LAZY 적용

-- session.getTimeSlot().getStartAt() 접근 시점에
select t1_0.id, t1_0.start_at
from time_slot t1_0
where t1_0.id = ?
-- 이때서야 별도 SELECT 발행

---

⑥ LazyInitializationException

현상: 영속성 컨텍스트(트랜잭션)가 닫힌 후 LAZY 프록시에 접근 → 예외 발생

// @Transactional 서비스에서 Session 반환
Session session = sessionService.findById(1L);
// → 메서드 반환 시 트랜잭션 종료, 영속성 컨텍스트 닫힘

// 컨트롤러에서 LAZY 필드 접근
session.

getTimeSlot().

getStartAt();
// → LazyInitializationException: could not initialize proxy - no Session

발생 흐름:

1. @Transactional 서비스에서 Session 로드
   → timeSlot은 미초기화 프록시 (SELECT 미발행)

2. 메서드 반환 → 트랜잭션 종료
   → 영속성 컨텍스트 닫힘

3. 컨트롤러에서 session.getTimeSlot().getStartAt()
   → 프록시 초기화 시도 → no Session
   → LazyInitializationException

주의 — 1차 캐시로 인한 함정:

같은 EntityManager에서 TimeSlot을 저장한 뒤 Session을 조회하면,
TimeSlot이 1차 캐시에 남아 프록시 대신 실제 객체를 반환한다.
이 경우 EM을 닫아도 예외가 발생하지 않아 문제를 놓치기 쉽다.

예외를 재현하려면 별도 EntityManager(별도 트랜잭션)로 조회해야 프록시가 생성된다.

실제 서비스에서 발생하는 시나리오:

1. spring.jpa.open-in-view=false 설정 (기본값 true → OSIV가 컨트롤러까지 세션 연장)
2. @Transactional 없는 컨트롤러에서 반환된 엔티티의 LAZY 필드를 JSON 직렬화

---

메서드 이름 쿼리 vs JPQL 선택 기준

메서드 이름 쿼리 (네임쿼리)

Spring Data JPA가 메서드명을 파싱해 쿼리를 자동 생성한다.
연관 엔티티 필드까지 경로 탐색(property traversal)을 지원한다.

// Waiting.session (Session) → Session.id (Long) 경로 탐색
List<Waiting> findBySessionId(Long sessionId);
// → SELECT w FROM Waiting w WHERE w.session.id = :sessionId

// 정렬 포함
List<Waiting> findBySessionOrderByIdAsc(Session session);
// → SELECT w FROM Waiting w WHERE w.session = :session ORDER BY w.id ASC

네임쿼리의 한계

한계	설명
집계/그룹핑 불가	GROUP BY, HAVING, COUNT 등 표현 불가
서브쿼리 불가	WHERE id IN (SELECT ...) 불가
JOIN FETCH 불가	N+1 문제를 쿼리 레벨에서 해결 불가
가독성 한계	조건이 3개 이상이면 메서드명이 파국

JPQL이 필요한 시점

// N+1 해결 — JOIN FETCH
@Query("SELECT w FROM Waiting w JOIN FETCH w.session WHERE w.session.id = :id")
List<Waiting> findWithSession(@Param("id") Long id);

// 집계
@Query("SELECT COUNT(w) FROM Waiting w WHERE w.session = :session AND w.id <= :id")
int countBefore(@Param("session") Session session, @Param("id") Long id);

// 서브쿼리 (WHERE/HAVING 절만 가능, FROM 절 불가)
@Query("SELECT w FROM Waiting w WHERE w.session.id IN " +
        "(SELECT s.id FROM Session s WHERE s.date > :date)")
List<Waiting> findAfterDate(@Param("date") LocalDate date);

JPQL의 한계 → 네이티브 쿼리

// FROM 절 서브쿼리, ROW_NUMBER(), 윈도우 함수 등은 JPQL 불가
// → @Query(nativeQuery = true) 또는 @Formula 사용
@Formula("(SELECT COUNT(*) FROM waiting w2 WHERE w2.session_id = session_id AND w2.id <= id)")
private Integer waitingNumber;

선택 기준 요약

상황	선택
단순 조건 1-2개 + 정렬	네임쿼리
조건 3개 이상 / 복잡한 이름	JPQL
N+1 해결 (JOIN FETCH)	JPQL
집계, 그룹핑	JPQL
서브쿼리 (WHERE/HAVING)	JPQL
윈도우 함수, FROM 서브쿼리	네이티브 쿼리 / @formula