3장 영속성 관리

해당 게시물은 책 '자바 ORM 표준 프로그래밍'을 읽고 작성했습니다.

👣 개요

엔티티 매니저가 엔티티를 어찌 관리하는지에 대한 게시물이다.

 

👣 Entity Manager Factory & Entity Manager

Entity Manager Factory
생성 비용이 아주 크며, 동시성에 강하기 때문에 App 전체에서 보통 1개만 사용한다.
META-INF/persistence.xml 내용을 기준으로 생성되며,
필요에 따라 Entity Manager를 만들어 낸다.

Entity Manager
비교적 생성 비용이 적다.
다만 동시성 문제에 취약하므로 스레드 사이에 공유는 절대 금물이다.
엔티티 매니저를 취득했다고 해서 DB와의 연결을 수행한 것은 아니다.
예를 들어 트랜잭션을 시작할 때만 DB와 연결을 수행한다고 보면 된다.

 

👣 영속성 컨텍스트

영속성 컨텍스트는 엔티티 매니저당 1개씩 할당되며,
해당 매니저를 통해 영속성 컨텍스트에 엔티티를 저장한다.
영속성 컨텍스트는 DB에 실제로 저장되기 전 중간 저장소라고 보면 된다.
엔티티는 영속성 컨텍스트에 4가지 상태로 남아있을 수 있다.
영속성 컨텍스트는 앞으로 PC라고 명명한다.

1. 비영속
PC에 저장된 적 없는 상태.
2. 영속
PC에 저장된 상태.
3. 준영속
PC에 저장된 적 있지만 현재는 분리된 상태.
4. 삭제
PC와 DB에서 삭제된 상태.

 

👣 영속성 컨텍스트 구조

,PC는 메모리 위에 있는 저장소라고 보면 된다.
PC는 1차 캐시와 쓰기 지연 SQL 저장소라는 곳이 있다.

1차 캐시 - 조회 지연
해당 장소는 빈번한 Select 쿼리를 막기 위해 엔티티 조회마다 DB로 쿼리를 보내는 것이 아닌
1차 캐시에서 찾아보고 없을 때만 그제서야 DB에 쿼리를 보내서 조회한다.

쓰기 지연 SQL 저장소 - 쓰기 저장소
해당 장소는 빈번한 Insert, Update, Delete를 막기 위해 트랜잭션 종료까지 정확히 말하자면
flush() 메서드 호출 전까지 잠시 보관하는 공간이다.
예를 들어, Member A 엔티티의 칼럼이 10개가 있고 소스 코드에 1개씩 10개의 수정 요청을 보내는 것이나
10개씩 1개의 수정 요청을 하는 것이나 어쨋든 똑같다는 것이다.
어차피 flush() 메서드 호출에 DB로 쿼리를 보내는 것이지 수정 요청을 보낼 때마다 DB로 쿼리를 보내는 것이 아니기에
마음껏 수정해도 된다는 것이다.

 

👣 flush

플러시는 PC와 DB가 동기화되도록 만드는 작업을 일컫는다.
flush를 직접 호출해 동기화시키는 방법도 있지만 몇몇 사례에서 자동으로 수행되기도 한다.

1. 직접 호출
2. 트랜잭션 커밋
3. JPQL 쿼리 실행

물론 사용자가 직접 플러시 시점을 결정할 수도 있다.

FlushModeType.AUTO
커밋이나 쿼리를 실행할 때, 플러시[기본값]

FlushModeType.COMMIT
커밋에만 플러시

 

👣 준영속

준영속 상태는 사실 거의 비영속 상태와 비슷하다.
하지만 영속 상태를 가지려면 무조건 식별자를 가지고 있어야 하므로
준영속 상태의 엔티티는 무조건 식별자를 가지고 있다고 볼 수 있다.
다음은 준영속 상태가 되는 방법 3가지다.

1. detach() 호출
특정 엔티티만 준영속화.
참고로 모든 1차 캐시와 쓰기 지연 SQL 저장소 모두에서 삭제한다.
2. clear() 호출
모든 엔티티를 준영속화.

 

👣 병합

준영속 상태를 다시 영속 상태로 변경하는 것을 말한다.
merge() 메서드를 이용해서 실현된다.
persist()는 비영속 엔티티를 영속으로 만들지만
merge()는 비영속, 준영속 엔티티를 영속을 만든다고 한다.