dirtyChecking

더티 체킹이란 repository.save()같은 메소드로 변경 사항을 저장하지 않아도 엔티티의 변경만으로 변경 사항이 저장되는 것을 말한다.

이하 블로그글 인용

출처 : https://jojoldu.tistory.com/415

"repository의 save 메소드로 변경 사항을 저장하지 않았음에도 update 쿼리가 실행되었습니다. 이유는 Dirty Checking 덕분인데요.

여기에서 Dirty란 상태의 변화가 생긴 정도로 이해하시면 됩니다. 즉, Dirty Checking이란 상태 변경 검사 입니다.

JPA에서는 트랜잭션이 끝나는 시점에 변화가 있는 모든 엔티티 객체를 데이터베이스에 자동으로 반영해줍니다.

이때 변화가 있다의 기준은 최초 조회 상태입니다.

JPA에서는 엔티티를 조회하면 해당 엔티티의 조회 상태 그대로 스냅샷을 만들어놓습니다. 그리고 트랜잭션이 끝나는 시점에는 이 스냅샷과 비교해서 다른점이 있다면 Update Query를 데이터베이스로 전달합니다."

정리

다시 정리하면 jpa가 엔티티를 영속성 콘텍스트에 보관할 때 최초 상태인 '스냅샷'을 보관하는데 플러시 시점에 보관했던 스냅샷과 변경된 엔티티를 비교해 어떤 것이 변경되었는지 찾아 데이터베이스로 보내는 것이다.

• 영속성 콘텍스트는 간단히 말해서 엔티티 매니저가 db와 소통하기 전, 애플리케이션 레벨에서 엔티티를 영구 저장하는 환경이다. 영속성 콘텍스트는 1차 캐시, 동일성 보장, 트랜잭션을 위한 쓰기 지연, 스냅샷 변경 감지 같은 특징이자 장점을 가지고 있다.

• 플러시는 말 그대로 전부 내려보내는 것으로, 영속성 컨텍스트가 관리하던 '쓰기 지연 sql 저장소'의 쿼리들을 db로 보내는 단계이다.

• 플러시는 (em은 엔티티 매니저) 1. em.flush() 2. transaction commit시 3. jpql실행 시 발생한다.

• 참고로 em.persist()시 영속성 컨텍스트가 pk로 엔티티를 관리하기 때문에 persist 시점에 pk를 찾을 수 없다면 flush없이도 db에 인서트 쿼리 후 pk값을 가져온다.

@DynamicUpdate

위에서는 dirty-checking에 대해서 알아보았다. transactional한 상태에서는 엔티티의 변경만으로도 db에 데이터를 변경할 수 있는 것이었다. 그런데 기본적으로 더티 체킹으로 생성되는 업데이트 혹은 인서트 쿼리는 모든 필드를 업데이트한다.

전체 필드를 업데이트하면 아래와 같은 장점이 있기 때문이다.

1. 생성되는 쿼리가 같아 부트 실행시점에 미리 만들어서 재사용가능

2. 데이터베이스 입장에서 쿼리 재사용이 가능 >> 동일한 쿼리를 받으면 이전에 파싱된 쿼리를 재사용

하지만 전체 필드를 업데이트하지 않고 싶을 수도 있는데 그 때 사용하는 것이 @Dynamicupdate이다. 이 어노테이션은 엔티티 위에 써주면 변경된 필드만 sql에 반영하게 해준다.

다만 이 어노테이션은 테이블에 컬럼이 20~30개 이상일 때 전체 필드의 업데이트가 느릴 수 있으므로 사용하는 것이고 테이블 필드가 적다면 굳이 사용할 필요가 없다.