JPA 영속성 컨텍스트와 변경 감지 (Dirty checking)

 

 

JPA 를 활용하면 필드 일부를 수정하는 경우 @Transactional 을 함께 사용하여 UPDATE 쿼리를 요청할 수 있다.
트랜잭션의 커밋 단위로 데이터베이스가 변경되며, 수정 사항이 있을 때마다 save() 를 할 필요가 없어진다.
이때 활용하는 것이 변경감지, 더티 체킹이다.

 

엔티티 매니저 (Entity Manage)

엔티티 매니저는 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리한다.

EntityManageFactory 를 활용하여 엔티티 매니저를 생성한다.

엔티티 매니저는 엔티티를 영속성 컨텍스트에서 보관하고 관리한다.

 

영속성 컨텍스트 (Persistence context)

직역하면 ‘엔티티를 영구 저장하는 환경’ 이다.

영속성 컨텍스트는 논리적인 개념에 가깝고 눈에 보이지도 않는다.

엔티티를 매니저를 생성할 때 하나 만들어지고, 엔티티 매니저를 통해 영속성 컨텍스트에 접근하고 관리할 수 있다.

엔티티를 식별자로 구분하기 때문에 영속 상태는 반드시 식별자 값이 있어야 한다.

 

엔티티의 생명주기

• New / Transient (비영속) : 엔티티 객체를 생성한 순순한 객체 상태로 아직 저장되지 않아서 영속성 컨텍스트 또는 DB와 전혀 관련이 없는 상태
• Managed (영속) : 앤티티 매니저를 통해 앤티티를 영속성 컨텍스트에 저장한 상태
• detached (준영속) : 영속성 컨텍스트에 저장되었다가 분리된 상태
• Removed (삭제) : 엔티티가 영속성 컨텍스트와 데이터베이스에서 삭제된 상태

 

1차 캐시

영속성 컨텍스트 내부 캐시를 의미한다. 영속 상태의 엔티티를 @Id로 매핑한 식별자 값을 통해 데이터베이스 기본 키와 매핑된다.

find()를 호출하면 먼저 1차 캐시에서 엔티티를 찾고 만약 찾는 엔티티가 1차 캐시에 없다면 데이터베이스에서 조회한다.

• 1차 캐시에서 조회 : 1차 캐시에 찾는 엔티티가 있으면 데이터베이스를 조회하지 않고 메모리에 있는 1차 캐시에서 조회한다.
• 데이터베이스에서 조회 : 없다면 데이터베이스에서 조회 후 1차 캐시에 저장한다. 저장한 영속 상태의 엔티티를 반환한다.

 

트랜잭션의 쓰기 지연 (Transactional write-behind)

엔티티 매니저가 트랜잭션을 커밋하기 직전까지 엔티티 정보를 데이터베이스에 저장하지 않고

내부 쿼리 저장소에 DML SQL 을 모아두었다가 커밋 시점에 데이터베이스에 한 번에 보내는 것

 

변경감지 (Dirty-checking)

영속성 컨텍스트에서 관리하는 영속 상태의 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능

동작 방식
트랜잭션을 커밋하면 엔티티 매니저 내부에서 스냅샷과 비교하며 변경된 엔티티를 찾는다.
변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰기 지연 저장소에 보낸다. 쓰기 지연 저장소의 SQL 을 데이터베이스에 보낸다.

💡 JPA 의 수정 쿼리 특징
JPA 에서 실행하는 UPDATE 문은 모든 필드를 업데이트한다. 이를 통해 수정 쿼리가 항상 동일하도록 하여 쿼리를 재사용할 수 있다.
칼럼이 30개 이상이 되면 기본적인 정적 수정 쿼리보다 @DynamicUpdate 를 사용한 동적 쿼리가 빠를 수 있다.

 

 

 

• 더티 체킹으로 인한 업데이트 오류 트러블 슈팅 포스팅 확인하기 

더티 체킹으로 인한 업데이트 오류 트러블 슈팅

 

---

[참고]

자바 ORM 표준 JPA 프로그래밍 - 예스24