[Spring Data JPA] 더티 체킹(Dirty Checking)

📌 더티 체킹

Transaction 안에서 엔티티의 변경이 일어나면 변경 내용을 자동으로 DB에 반영하는 것
Dirty ➡️ 상태의 변화 / Checking ➡️ 검사

ex. 주문 취소 기능

@Transactional  
public void cancelOrder(Long orderId) {  
    //주문 엔티티 조회  
    Order order = orderRepository.findOne(orderId);  

    //주문 취소  
    order.cancel();  
}

➡️ orderId를 통해 주문을 취소하는 메소드

• 트랜잭션 시작
• orderId로 주문 Entity 조회
• 해당 Entity 주문 취소 상태로 Update
• 트랜잭션 커밋

JPA에서는 트랜잭션이 끝나는 시점에 변화가 있던 모든 엔티티의 객체를 DB로 알아서 반영을 해줌

• JPA에서 Entity 조회
• 조회된 상태의 Entity에 대한 스냅샷 생성
• 트랜잭션 커밋 후 해당 스냅샷과 현재 Entity 상태의 다른 점 체크
• 다른 점들을 update 쿼리로 DB에 전달

📌 더티 체킹 조건

✔️ 영속성 컨텍스트에서 관리되는 엔티티
준영속, 비영속 엔티티는 값을 변경해도 DB에 반영X

✔️ Transaction이 커밋되었을 때
트랜잭션이 커밋되기 전까지 영속성 컨텍스트는 변경사항을 추적하기만 하고 DB에 반영X
➡️ 트랜잭션이 커밋될 때 영속성 컨텍스트는 엔티티의 변경된 상태를 DB에 반영

➕ 영속성 컨텍스트
엔티티를 영구 저장하는 환경

➕ 엔티티 생명주기

• 비영속(new/transient): 영속성 컨텍스트와 전혀 관계가 없는 상태
• 영속(managed): 영속성 컨텍스트에 저장된 상태
• 준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태
• 삭제(removed): 삭제된 상태

📌 @DynamicUpdate

기본적으로 더티 체킹을 실행하면 SQL에서는 변경된 엔티티의 모든 내용을 update 쿼리로 만들어 전달
➡️ 필드가 많아지면 전체 필드를 update 하는 것이 비효율적

@Getter
@NoArgsConstructor
@Entity
@DynamicUpdate
public class Order {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String product;

➡️ @DynamicUpdate를 해당 엔티티에 선언하여 변경 필드만 반영

[참고 자료]

🔗링크
🔗링크