JPA 변경 감지(dirty checking)와 병합(merge)

영속성 컨텍스트와 준영속

영속성 컨텍스트(persistence context)

엔티티 매니저로 엔티티를 저장하거나 조회하면 영속성 컨텍스트가 엔티티를 보관하고 관리한다.
트랜잭션을 커밋할 때 영속성 컨텍스트에서 새로 저장되거나 수정된 엔티티를 DB에 반영한다(flush).
애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다.

준영속(detached)

영속성 컨텍스트가 더 이상 관리하지 않는 엔티티를 뜻한다.

수정 폼에서 넘어온 데이터로 엔티티를 갱신할 때, 변경 내용을 DB에 반영하는 방법은 두 가지다.

병합(merge)

@PostMapping("items/{itemId}/edit")
public String updateItem(@PathVariable String itemId, @ModelAttribute("form") BookForm form) {

    Book book = new Book();
    book.setId(form.getId());
    // ... 나머지 값 설정

    itemService.saveItem(book);
    return "redirect:/items";
}

public void saveItem(Item item) {
    if (item.getId() == null) {
        em.persist(item); // 신규 등록
    } else {
        em.merge(item); // 병합
    }
}

폼 데이터를 새로 만든 Book 객체에 setter로 채워 넣어도 DB에는 자동으로 반영되지 않는다. 이 book은 직접 new로 만든 객체일 뿐, 영속성 컨텍스트가 관리하는 영속 상태의 엔티티가 아니기 때문이다. 식별자는 갖고 있지만 관리되지 않는 준영속 상태다.

이를 반영하는 방법이 merge다. 같은 식별자를 가진 영속 엔티티에 내가 만든 book의 값을 병합해 준다.

문제는 병합이 모든 필드를 교체한다는 점이다. 값을 설정하지 않은 필드도 그대로 병합되므로 기존 값이 null로 덮어써질 수 있다. 그래서 실무에서는 병합을 사용하지 않는 것이 좋다.

변경 감지(dirty checking)

@Transactional
void update(Item itemParam) { // itemParam: 파라미터로 넘어온 준영속 상태의 엔티티
    Item findItem = em.find(Item.class, itemParam.getId()); // 같은 식별자의 엔티티를 조회한다.
    findItem.setPrice(itemParam.getPrice()); // 데이터를 수정한다.
}

여기서 findItem도 merge를 호출해야 할까? 그럴 필요가 없다. em.find로 조회한 엔티티는 영속 상태이기 때문이다. 트랜잭션이 커밋될 때 영속성 컨텍스트가 변경된 부분을 감지해 UPDATE를 자동으로 반영한다.

변경 감지는 원하는 필드만 골라서 수정할 수 있으므로 병합처럼 의도하지 않은 null 덮어쓰기가 생기지 않는다.

참고

김영한, 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 (인프런)
[JPA] 영속성(persistence)이란? - Aaron