SpringBoot를 공부하다보면 Dirty checking이란 단어가 자주 등장한다. JPA는 엔티티 매니저가 엔티티를 저장, 조회, 수정, 삭제하는데 수정 메소드는 작성하지 않는다.
이는 Dirty Checking 덕분이다.
더티체킹은 Transaction 안에서 엔티티 변경이 일어나면, 변경 내용을 자동으로 DB에 반영해주는 JPA 특징이다.
Dirty란 상태의 변화가 생긴 정도라고 한다. 그러므로 Dirty Checking은 상태 변경 검사라고 할 수 있다.
DB에 변경 데이터를 저장하는 시점
(1) Transactional commit 시점
(2) EntityManager flush 시점
(3) JPQL 시점
JPA는 트랜잭션이 끝나는 시점, 변화가 있는 모든 엔티티 객체를 데이터베이스에 자동으로 반영해준다. 이때, 변화의 기준은 최초 조회 상태 이다.
JPA에서는 엔티티를 조회하면 해당 엔티티의 조회 상태 그대로 스냅샷 을 만들어놓는다.
그리고 트랜잭션이 끝나는 시점 그 스냅샷과 비교해 변화가 생겼다면 UPDATE query를 날린다.
당연히 이런 상태 변경 검사의 대상은 영속성 컨텍스트가 관리하는 엔티티에만 적용된다.
즉,
- 영속상태(managed)의 엔티티이거나
- Transaction 안에서 엔티티를 변경한 경우
에 더티 체킹이 가능하다는 것이다.
- Detach된 엔티티(준영속)
- DB에 반영되기 전 처음 생성된 엔티티(비영속)
위 두 가지의 경우 준영속, 비영속 상태의 엔티티이기 때문에 대상에 포함되지 않는다.
그리고 더티 체킹은 기본적으로 전체 필드를 업데이트 하는 방식이다.
이렇게 전체 필드가 업데이트 되면
- 생성되는 쿼리가 같이 부트 실행 시점에 미리 만들어 재사용이 가능
- 데이터베이스 입장에서 쿼리 재사용이 가능(동일 쿼리를 받으면 이전 파싱된 쿼리 재사용)
이러한 장점을 가진다.
개발 바보 이사 중