[🌱 JPA 방탈출 예약 대기] 제제(송민서) 미션 제출합니다.

[alstj2384]

체크 리스트

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

베이스 코드 선택 체크

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

도달 지점

4단계 자동 승인

영속성 컨텍스트 관찰

발행 SQL을 직접 보면서 영속성 컨텍스트 동작을 확인했습니다.

1차 캐시: 같은 트랜잭션에서 findById를 5번 호출 → SELECT 1번만 발행
dirty checking: 수정 로직에서 update/save를 명시적으로 호출하지 않아도, 영속 객체 필드만 바꾸면 commit 시점에 UPDATE 자동 발행. 기존 JdbcTemplate 코드의 reservationRepository.update(...) 호출 자체가 사라짐
DDL 관찰: @column(length = 20)은 의도대로 varchar(20), 하지만 제약을 안 주면 기본이 nullable이라 start_at이 의도와 달리 null 허용으로 나옴 → @column(nullable = false) 추가로 수정했습니다.
LocalTime은 time(6)로 저장되었는데, DB의 시간 단위와 자바의 시간 단위 정밀도를 맞추려고 이렇게 수정됨을 알게 되었습니다

2단계 연관관계 매핑

단방향 @manytoone으로 매핑하니, FK 제약이 테이블 생성 후 alter table로 나중에 추가되고, FK 이름은 하이버네이트가 FK + 해시로 자동 생성했습니다.

findById(id).getTime().getStartAt()의 발행 SQL을 확인 시 LAZY로 두면 프록시로 두고 실제 접근 시점에 추가 SELECT하는 것을 확인했습니다.

3단계 N+1을 직접 목격

findAll로 예약을 다 가져온 뒤, Reservations 일급 컬렉션 안에서 각 Reservation의 slot 프록시에 접근하니 쿼리가 엄청 많았습니다.
예약 4건 조회 → Reservation 전체 조회 1번 + 레코드 수만큼 slot 조회 N번 + DTO 변환 시 time + theme 예약자 record 당 2번
= 의도하지 않은 수십 번의 쿼리

@query로 fetch join을 넣어 slot을 한 방에 끌어왔습니다.

java@Query("SELECT r FROM Reservation r JOIN FETCH r.slot s")
List<Reservation> findAll();

흔들린 한 장면: "왜 @transactional이 없는데 1차 캐시가 먹지?"

1차 캐시를 확인하다가, Service에서 @transactional을 떼고 findById를 5번 호출했는데요, 제 가설대로면 쿼리가 5번 나가야 했는데, 한 번만 나갔습니다. 영속성 컨텍스트는 트랜잭션 범위에서만 산다고 알고 있었는데, 트랜잭션이 없는데도 캐시가 살아있었습니다.
그 이유는 OSIV였습니다. HTTP 요청 진입 ~ 응답까지 영속성 컨텍스트를 살려두니, 트랜잭션이 없어도 웹 요청 한 사이클 동안 1차 캐시가 유지된 겁니다. spring.jpa.open-in-view=false로 끄니, 의도대로 SELECT가 5번 나갔습니다.

왜 영속성 컨텍스트 생명주기는 트랜잭션인가?

• 1차 캐시를 언제까지 유지할지의 기준이 필요하다.
• 영속성 컨텍스트는 스레드 안전하지 않다 — 스레드 격리 기준이 필요하다.
• 쓰기 지연의 flush 시점 기준이 필요하다.

위 기준에 의해 컨텍스트 생명주기가 설정됨을 알게 되었습니다.
OSIV는 이 경계를 인위적으로 늘려 잠깐의 편의를 주는 대신, 커넥션을 응답 끝까지 유지하여 커넥션 고갈 위험이 있다는 단점이 있는 점을 알게 되었습니다.