🔎 Overview

 금일 학습 중 궁금한 점이 생겼다.

 update 작업을 실행하니, 쿼리가 아래와 같이 출력되었다.

Hibernate: 
    select
        q1_0.id,
        q1_0.content,
        q1_0.create_date,
        q1_0.subject 
    from
        question q1_0 
    where
        q1_0.id=?

Hibernate: 
    insert 
    into
        answer
        (content, createdate, question_id, id) 
    values
        (?, ?, ?, default)

Hibernate: 
    select
        q1_0.id,
        q1_0.content,
        q1_0.create_date,
        q1_0.subject 
    from
        question q1_0 
    where
        q1_0.id=?

  왜 select가 update 전후로 2번이나 실행이 되었을까? 그 원인은 JPA의 Dirty Checking이었다.

---

📕 Dirty Checking

• JPA 가 영속성 컨텍스트에 관리되는 엔티티의 상태를 검사하고, 그 중 변경된 부분만 DB 에 반영하는 기능
• 보다 효율적인 DB 업데이트 가능
• 추가적인 SQL 쿼리 작성이 필요 없이, 트랜잭션 내에서 엔티티 상태만 변경해주면 자동으로 반영
• DB 와 애플리케이션 간의 작업을 최적화

---

📈 Dirty Checking의 작동 원리

• 영속성 컨텍스트와 _엔티티의 초기 상태(스냅샷)을 비교하여 동작
  
  

1) 영속성 컨텍스트

• JPA 는 엔티티 의 저장 및 조회 시 영속성 컨텍스트 에 엔티티 저장
• 영속성 컨텍스트는 이 엔티티의 초기 상태(스냅샷)를 유지
• 이후 엔티티의 변경사항 감시
  
  

2) 스냅샷

• 영속성 컨텍스트에 저장된 엔티티의 초기 상태
• JPA 는 트랜잭션의 커밋 시점에 엔티티의 현재 상태와 스냅샷의 비교를 통해 변경 사항 감지
  
  

3) 변경 감지

• 영속성 컨텍스트의 엔티티와 스냅샷을 비교하여 변경된 필드 확인
• 변경된 필드가 존재하면 UPDATE 쿼리 실행
• 변경된 필드가 없으면 쿼리를 실행하지 않음
• DB에 변경 사항 저장(반영)

---

📑 Dirty Chekcing의 특징

1) 트랜잭션과의 연관성

• Dirty Checking 은 반드시 트랜잭션의 커밋 시점에 동작
• 즉, 트랜잭션 내에서만 동작하므로 @Transactional 어노테이션이 반드시 필요
  
  

2) 영속 상태에서만 동작

• 준영속 상태에서는 동작하지 않음

---

‼️ Dirty Checking의 장점

• 개발 생산성 향상
  • 확실히 변경된 엔티티만 자동으로 반영하므로, 수동 쿼리 작성의 번거로움 감소
• 자동화된 데이터 동기화
  • 엔티티 객체와 데이터베이스 간의 상태 동기화를 자동으로 처리

---

🤔 지연 로딩에서 Dirty Checking이 예상치 못한 SELECT 쿼리를 발생시키는 이유

• Dirty Checking의 경우, 커밋 시점에 영속성 컨텍스트의 엔티티와 스냅샷을 비교

• 이 비교 과정에서 Lazy Loading 필드 또한 마찬가지로 체킹 시도

• Lazy Loading된 연관 필드는 실제 데이터를 가져오지 않고서는 비교가 불가능

• 스냅샷과의 비교를 위해서 DB 에서 데이터를 가져오는 추가적인 SELECT 쿼리 발생

‼️ Dirty Checking은 연관된 Lazy Loading 필드의 변경 여부도 확인하며, 로딩되지 않았을 경우 JPA 는 DB 에서 해당 데이터 로드를 통해 확인 시도

🙅 이러한 상호작용의 문제점

1) 불필요한 쿼리로 인한 성능 저하

• 필요없는 SELECT 쿼리를 실행하므로 성능 저하

2) 의도치 않은 동작 발생

• Lazy Loading 데이터가 예상치 않게 로딩될 경우, 데이터가 개발자의 의도와는 다르게 처리될 가능성 발생
  • 특정 트랜잭션에서 DB 로드 없이 처리하려 했지만, Lazy Loading으로 인해 불필요한 데이터를 가져옴
  • 이로 인한 side effect 발생 가능

3) N+1 문제

• 부모 엔티티 1개를 조회할 때, 자식 엔티티 N 번을 개별적으로 조회하는 추가 쿼리 발생
• 예시

@Entity
public Class User {
	@Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    private List<Order> orders;
}

@Entity
public Class Order {
	@Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private User user;
}

List<User> users = userRepository.findAll();	// 부모 엔티티를 가져옴
for (User user : users) {
	user.getOrders().size()	// 자식 엔티티(Order) 조회 (N번의 쿼리 추가 실행)
}

• 한 트랜잭션 내에서 실행된다고 가정
• User 의 연관 관계인 Order 가 Lazy Loading으로 설정되어 있기 때문에, List<Order> 를 개별적으로 가져오며 성능 저하 유발

4) 트랜잭션 범위와 Lazy Loading

• 트랜잭션 범위를 벗어나서 Lazy Loading 필드에 접근하면 LazyInitializationException 발생
• 이는 트랜잭션이 끝난 후 Lazy Loading 필드를 접근하면, JPA가 처리할 수 없기 때문

---

💡 이러한 문제를 피하는 방법

1) 연관 데이터의 로딩을 금지

• 연관된 Lazy Loading 필드가 불필요하게 Dirty Checking 되는 것을 사전에 방지

2) Fetch 전략 수정

• 연관 필드의 FetchType 을 LAZY 대신 EAGER 로 변경
• 이 방법을 사용하면 필요하지 않은 데이터를 항상 로딩하므로 성능 저하 발생
• 그러므로 추천하는 방법은 아님

3) 엔티티 분리

• 연관 엔티티는 조회하지 않도록 DTO 등을 사용해서 사전에 분리

4) 영속성 컨텍스트 관리

• Dirty Checking 발생 전, 연관된 Lazy Loading 데이터를 강제로 로드
• 혹은 필요 없는 경우, detach() 를 이용하여 제거

Hibernate.initialize(user.getOrders());	// Lazy Loading 강제 초기화, 트랜잭션 범위 내에서 강제로 로드 가능
entityManager.detach(user)	// 영속성 컨텍스트에서 제거

---

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/