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

[wontop02]

체크 리스트

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

베이스 코드 선택 체크

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

0. 사전학습 - 키워드

패러다임 차이

• ORM : 객체 지향 프로그래밍의 객체와 관계형 데이터베이스의 테이블을 자동으로 연결해주는 기술이다.
• 객체-관계 임피던스 불일치: 객체 지향 언어의 데이터 구조와 관계형 데이터베이스의 테이블 구조가 불일치하는 것을 말한다.
• 영속성: 데이터를 생성한 프로그램이 종료되어도 데이터가 사라지지 않고 유지되는 특성을 말한다.

핵심 개념

• 영속성 컨텍스트: 엔티티를 영구 저장하는 환경으로, 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다.
• 1차 캐시: 엔티티를 DB에 저장하기 전에, 임시로 영속성 컨텍스트에 저장하는 것이다.
• dirty checking: 영속성 컨텍스트가 1차 캐시에 존재하는 엔티티의 스냅샷을 트랜잭션 커밋 시점에 현재의 엔티티와 비교해, 변경을 감지하고 자동으로 UPDATE SQL을 생성하는 것이다.
• 쓰기 지연: 트랜잭션이 커밋되기 전까지 DB로 쿼리를 날리지 않고 영속성 컨텍스트의 쓰기 지연 SQL 저장소에 보관해두는 것이다.
• flush: 트랜잭션이 커밋되는 시점에 SQL을 모두 DB로 전달하는 것을 의미한다.

매핑

• @Entity: 해당 클래스가 관계형 데이터베이스에 매핑되는 영속성을 가진 엔티티라는 것을 표현하는 어노테이션이다.
• @Id: 해당 필드가 엔티티를 식별하는 Primary Key라는 것을 표현하는 어노테이션이다.
• @GeneratedValue: Primary Key의 값을 생성하는 전략을 표현하는 어노테이션이다.
• @Column: 객체의 필드를 테이블의 컬럼에 매핑시켜주는 어노테이션이다.
• @Table: 엔티티 클래스의 테이블을 정의하는 어노테이션이다.

연관관계

• @ManyToOne: 여러 개의 엔티티가 @ManyToOne이 정의된 해당 필드의 동일한 엔티티를 가질 수 있다는 것을 의미한다.
• @OneToMany: 하나의 엔티티가 @OneToMany가 정의된 해당 필드의 여러 엔티티를 가질 수 있다는 것을 의미한다.
• 단/양방향
  • 단방향: 두 엔티티가 관계를 맺을 때, 한 쪽의 엔티티만 참조하는 것이다.
  • 양방향: 두 엔티티가 관계를 맺을 때, 양 쪽의 엔티티가 서로 참조하는 것이다.
• 연관관계 주인: 연관 관계를 갖는 엔티티 중 많은 쪽, 즉 다른 엔티티의 외래키를 가지는 엔티티가 연관관계의 주인이 되어 외래 키를 변경할 수 있다.
• cascade: 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 전이되는 것을 말한다.
• orphanRemoval: 부모 엔티티와의 연관 관계가 끊어진 자식 엔티티를 자동으로 삭제하는 옵션이다.

페치

• EAGER: 즉시 로딩을 의미하는 말로, 데이터 조회 시 연관된 데이터까지 한 번에 조회하는 것이다.
• LAZY: 지연 로딩을 의미하는 말로, 데이터 조회 시 연관된 데이터는 실제로 사용할 때만 조회하는 것이다.
• fetch join: 연관된 엔티티나 컬렉션을 SQL 조인문으로 한 번에 조회할 수 있는 기능이다.
• @EntityGraph: JPQL로 fetch join을 직접 작성하지 않고, 해당 어노테이션을 붙여서 fetch join을 적용할 수 있다.

쿼리

• JPQL: 테이블이 아닌 엔티티 객체를 대상으로 검색하는 객체지향 쿼리 언어이다.
• Native Query: JPA에서 JPQL 대신 SQL 쿼리를 직접 작성해 사용할 수 있는 방법이다.

1. 1단계 - 영속성 컨텍스트 관찰

1. 관찰 대상: dirty checking

• 어떤 코드로 확인하는가: @Transactional 메서드에서 entity 필드 수정 후 save 미호출
• 무엇을 본다: commit 시점에 UPDATE 자동 발행

@Transactional  
public Theme save(Theme theme) {  
    themeRepository.save(theme);  
    theme.setName("change");  
    System.out.println("아이디 생성됨: " + theme.getId());  
    return theme;  
}

• @Transactional 내부에서 수정해야 함
  • 영속성 컨텍스트는 트랜잭션과 생명 주기가 같기 때문에, 트랜잭션 범위 내에서의 변화만 감지할 수 있음
  • 영속성 컨텍스트는 객체가 관리되는 공간을 말함
• 영속 상태여야 함 (save, find 등)

2. 관찰 대상: 1차 캐시

• 어떤 코드로 확인하는가: 같은 트랜잭션에서 findById 두 번 호출
• 무엇을 본다: 두 번째 SELECT 생략 (1차 캐시 적중)

public Reservation findReservation(Long reservationId) {  
    System.out.println("첫 번째 findById() 호출 시작");  
    reservationRepository.findById(reservationId);  
    System.out.println("첫 번째 findById() 호출 끝");  
    System.out.println("두 번째 findById() 호출 시작");  
    Optional<Reservation> reservation = reservationRepository.findById(reservationId);  
    System.out.println("두 번째 findById() 호출 끝");  
    return reservation.get();  
}

• 두 번째는 SQL문이 사용되지 않음

3. 관찰 대상: 쓰기 지연

• 어떤 코드로 확인하는가: save 호출 후 flush 전·후의 DB 상태 비교
• 무엇을 본다: INSERT가 commit/flush 시점에 일괄 발행

// Theme의 GeneratedValue 주석 처리

@Test  
void test() {  
    Theme theme1 = new Theme(1L, "방탈출1", "설명", "썸네일");  
    Theme theme2 = new Theme(2L, "방탈출2", "설명", "썸네일");  
  
    System.out.println("첫 번째 save 호출 전");  
    themeRepository.save(theme1);  
    System.out.println("첫 번째 save 호출 끝");  
  
    System.out.println("두 번째 save 호출 전");  
    themeRepository.save(theme2);  
    System.out.println("두 번째 save 호출 끝");  
  
    System.out.println("flush 호출 전");  
    entityManager.flush();  
    System.out.println("flush 호출 후");  
}

• select는 객체가 이미 존재하는지 확인하기 위해 호출되는 것
  • 없으면 INSERT 쿼리를 쓰기 지연 저장소에 담아둠
  • 있으면 UPDATE 쿼리를 쓰기 지연 저장소에 담아둠
• flush 시점에 INSERT가 날아감

4. 관찰 대상: flush 시점

• 어떤 코드로 확인하는가: 명시적 flush 호출 / 트랜잭션 종료 / JPQL 실행 직전
• 무엇을 본다: 영속성 컨텍스트 → DB 동기화 트리거

// Theme의 GeneratedValue 주석 처리

@Test  
void test() {  
    Theme theme1 = new Theme(1L, "방탈출1", "설명", "썸네일");  
    Theme theme2 = new Theme(2L, "방탈출2", "설명", "썸네일");  
  
    System.out.println("첫 번째 save 호출 전");  
    themeRepository.save(theme1);  
    System.out.println("첫 번째 save 호출 끝");  
  
    System.out.println("두 번째 save 호출 전");  
    themeRepository.save(theme2);  
    System.out.println("두 번째 save 호출 끝");  
  
    System.out.println("findAll 호출 전");  
    themeRepository.findAll();  
    System.out.println("findAll 호출 후");  
}

• save를 호출할 때는 insert문이 되지 않는데, findAll(JPQL)이 호출되니 flush를 직접 하지 않아도 기존의 insert가 모두 호출됨
• JPQL 실행 직전에 flush가 자동으로 호출됨
• flush 기준으로 트랜잭션이 끝나는 건 줄 알았는데, 그건 또 아니라고 함. 트랜잭션을 끝나려면 commit을 해야 하는데, 스프링이 트랜잭션을 끝낼 때 알아서 flush를 호출하고 commit하기 때문에 헷갈린 것

5. 관찰 대상: fetch 기본값

• 어떤 코드로 확인하는가: @ManyToOne vs @OneToMany 무명시 시
• 무엇을 본다: 영속성 컨텍스트 → DB 동기화 트리거

// Slot의 @ManyToOne LAZY 무명시, 명시

• fetch 즉시 로딩(기본값) - EAGER

• fetch 지연 로딩 - LAZY

• select문을 2번 날려 Reservation과 ReservationTime을 따로 가져오고, 안 쓰이고 있는 Theme은 가져오지 않는다.

6. 관찰 대상: LazyInitializationException

• 어떤 코드로 확인하는가: 트랜잭션 밖에서 LAZY 필드 접근
• 무엇을 본다: 영속성 컨텍스트 닫힌 후 프록시 미초기화

@Test  
void test() {  
    Theme theme = themeRepository.save(new Theme("공포 방탈출", "설명", "썸네일"));  
    ReservationTime time = timeRepository.save(new ReservationTime(LocalTime.of(14, 0)));  
    Reservation savedReservation = reservationRepository.save(  
            new Reservation("주영", new Slot(LocalDate.of(2026, 5, 2), time, theme)));  
  
    Long targetId = savedReservation.getId();
  
    System.out.println("예약 조회 시작 (Reservation 내부에서 트랜잭션 열리고 닫힘)");  
    Reservation reservation = reservationRepository.findById(targetId).orElseThrow();  
    System.out.println("예약 조회 끝 (영속성 컨텍스트 사라짐, reservation은 준영속 상태)");  
  
    System.out.println("프록시 객체 가져오기");  
    ReservationTime proxyTime = reservation.getTime();  
    System.out.println("프록시 객체 초기화 시도");  
    proxyTime.getStartAt();  
}

• Reservation이 timeId와 themeId를 갖고 있기 때문에, 프록시 객체는 ID만 갖고 있음. 그래서 proxyTime.getId();하면 예외 발생하지 않음

2. 2-3단계 - LAZY 로딩의 한계

LAZY 로딩을 무분별하게 사용하면 N+1 문제가 발생해 성능이 저하될 수 있다.

• LAZY 로딩 방식

1. findByMemberId는 Reservation 테이블만 SELECT해서 가져온다.
2. Response DTO를 만들 때 Reservation이 갖고 있는 Time, Theme 엔티티의 필드에 접근하면 LAZY 로딩이 발동해서 Time, Theme 테이블에서 다시 가져와야 한다.
   => 예약이 10개이면 각 예약의 테마와 시간을 초기화하기 위해 추가 쿼리가 20번 나가는 문제가 발생한다.

이 경우는 @Query를 써서 JPQL로 페치 조인을 명시하거나, @EntityGraph를 써야 문제를 해결할 수 있다.

4단계 - 예약 취소, 대기 자동 승인

• 예약 취소하고, 첫 번째 대기를 예약으로 승인하는 과정의 SQL문을 보려고 했으나 DataIntegrityViolationException이 발생함(Unique 제약 조건 위반)

  • 이유: 로직은 예약 DELETE 이후 대기를 예약으로 변환해 예약 INSERT 순서대로 되어 있지만, 하이버네이트(JPA)의 쿼리 실행 순서는 트랜잭션이 끝날 때 INSERT 먼저 실행하고 DELETE를 실행하도록 되어 있기 때문

• 작성 코드

@Transactional  
public void deleteReservation(Long id) {  
    Reservation reservation = reservationService.findReservation(id);  
  
    Slot slot = new Slot(reservation.getDate(), reservation.getTime(), reservation.getTheme());  
    Waits waits = waitService.findBySlot(slot);  
  
    if (waits.isEmptyWaitsBySlot(slot)) {  
        reservationService.delete(reservation, false);  
        return;  
    }  
    System.out.println("예약 삭제 시작");  
    reservationService.deleteAndFlush(reservation, false);  
    System.out.println("예약 삭제 완료");  
    confirmFirstWait(waits.firstWaitBySlot(slot));  
    System.out.println("예약 삭제, 첫 번째 대기 자동 승인 끝");  
}

private void confirmFirstWait(Wait firstWait) {  
    Reservation reservationWithoutId = new Reservation(firstWait.getMember(),  
            new Slot(firstWait.getReservationDate(), firstWait.getTime(), firstWait.getTheme()));  
    System.out.println("첫 번째 대기를 예약으로 생성 시작");  
    reservationService.save(reservationWithoutId, true);  
    System.out.println("첫 번째 대기를 예약으로 생성 끝");  
    System.out.println("첫 번째 대기 삭제 시작");  
    waitService.delete(firstWait.getId(), true);  
    System.out.println("첫 번째 대기 삭제 끝");  
}

• 실행 결과

예약 삭제 시작
Hibernate: 
    delete 
    from
        reservation 
    where
        id=?
예약 삭제 완료
첫 번째 대기를 예약으로 생성 시작
Hibernate: 
    insert 
    into
        reservation
        (member_id, reservation_date, theme_id, time_id, id) 
    values
        (?, ?, ?, ?, default)
첫 번째 대기를 예약으로 생성 끝
첫 번째 대기 삭제 시작
첫 번째 대기 삭제 끝
예약 삭제, 첫 번째 대기 자동 승인 끝
Hibernate: 
    delete 
    from
        wait 
    where
        id=?

• "예약 삭제, 첫 번째 대기 자동 승인 끝"이라는 메시지를 코드 맨 밑에 작성해뒀는데, 메서드가 다 실행된 후에 DELETE 쿼리가 실행됨. 즉, flush를 안 하면 트랜잭션이 끝날 때 쿼리문이 DB로 보내진다는 뜻

• 트랜잭션이 끝난 후 쿼리문은 INSERT -> UPDATE -> DELETE 순으로 보내짐