[JPA] 영속성 컨텍스트

영속성 컨텍스트

엔티티를 영구히 저장하고 관리하는 공간

 

1. 영속성 컨텍스트와 식별자 값 (@Id로 테이블의 기본 키와 매핑한 값)

영속성 컨텍스트는 엔티티를 식별자 값으로 구분한다.

따라서 영속 상태는 식별자 값이 반드시 있어야 한다.

식별자 값이 없으면 예외가 발생한다.

 

2. 영속성 컨텍스트와 데이터베이스 저장

Flush : JPA가 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는 작업

 

3. 영속성 컨텍스트가 엔티티를 관리 성능 이점.

- 1차 캐시

- 동일성 보장

- 트랜잭션을 지원하는 쓰기 지연

- 변경감지

- 지연로딩

 

1차 캐시 : 영속성 컨텍스트가 내부에서 엔티를 관리하고 있는 장소

조회 로직

1) 1차캐시에 엔티티가 존재하는 경우

find > 1차캐시 조회 > 반환 

2) 1차캐시에 엔티티가 존재하지 않고 DB에 존재하는 경우

find > 1차캐시 조회 > DB조회 > 1차캐시에 저장 (영속) > 반환

 

find로 찾은 엔티티는 동일성 ( a == b ) 가 보장된다.

 

쓰기지연

엔티티 매니저가 트랜잭션을 커밋하기 전 까지 내부쿼리 저장소에 Insert SQL을 모아두는 곳

이 기능을 잘 이용하면 쿼리를 DB에 한번에 전달 해 성능을 최적화 할 수 있다.

 

더티체킹

영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용되는 작업

플러시 시점에 스냅샷과 엔티티를 비교해서 변경된 엔티티에 대해 UPDATE쿼리를 생성하고 DB에 반영한다.

SQL 수정 쿼리의 문제점 : 비지니스 로직이 SQL을 간섭하게 됨 ( 수정할 필드가 추가되면 SQL문도 변경 )

 

* 스냅샷

엔티티의 최초상태를 복사해서 저장해놓은 데이터

 

*기본전략은 테이블의 모든 필드를 Update한다.

DynamicUpdate를 통해 변경된 필드만 Update를 할 수 있지만, DynamicUpdate는 쿼리생성캐시를 사용하지 않고 동적으로 쿼리를 생성하여 오버헤드가 발생한다.

필드가 많고 Update 필드가 적은 경우는 DynamicUpdate를 활용하는 방법도 있겠지만, 이 떄는 테이블이 적절하게 생성되어 있는지 확인할 필요가 있다.

 

삭제

삭제도 마찬가지로 쓰기 지연 SQL 저장소에 등록된다.

하지만 em.remove를 호출하는 순간 영속성 컨텍스트에서 제거되며, 재사용을 하지말고 GC의 대상이 되도록 하는 것이 좋다.

 

Flush

영속성 컨텍스트의 변경 내용을 DB에 반영하는 작업 (DB와 영속성 컨텍스트간의 동기화)

변경 감지를 통해 수정쿼리를 생성하고, 쓰기 지연 SQL저장소의 쿼리를 DB에 저장한다.

 

* 호출방법

직접호출 : em.flush()

트랜잭션 커밋

JPQL 쿼리 실행 

 

javax.persistence.FlushModeType : COMMIT 속성을 통해 커밋할 떄만 플러시를 동작 시킬 수 있다.

 

준영속

영속성 컨텍스트 관리대상에서 벗어난 엔티티이다.

- detach(entity); : 특정엔티티만
- clear : 영속성 컨텍스트 초기화
- close : 영속성 컨텍스트종료

 

비영속 데이터와 다른점은 영속상태에서 준영속 상태로 변경되었기 때문에 식별자 값을 가지고있다.

 

merge() : 병합

준영속, 비영속 상태의 엔티티를 병합해 새로운 영속 상태의 엔티티를 반환