영속성 컨텍스트

영속성 컨텍스트

2023. 5. 17. 00:33ㆍBackEnd(Java)/JPA 개념

✅ 아래 내용들에 대해서 알아보자

- 엔티티 매니저 팩토리와 앤티티 매니저
- 영속성 콘텍스트
- 엔티티 생명주기
- 영속성 콘텍스트 특징
- 플러시
- 준영속

엔티티 매니저 팩토리와 앤티티 매니저

DB를 하나만 사용하는 애플리케이션은 일반적으로 EntityManagerFactory를 하나만 생성한다.

EntityManagerFactory emf=Persistence.createEntityManagerFactory("jpabook");

앤티티 매니저 팩토리는 이름 그대로 앤티티 매니저를 만드는 공장 역할을 하며, 공장을 만드는 비용은 상당히 크다.

따라서 하나의 엔티티 매니저 팩토리를 생성하여 공유하도록 설계되어 있다. 반면 공장에서 엔티티 매니저를 생성하는 비용은 거의 들지 않는다.

앤티티 매니저 팩토리는 여러 스레드가 동시 접근해도 안전하므로 서로 다른 스레드 간에 공유해도 되지만, 엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드 간에 절대 공유하면 안 된다!!

위 그림을 보면 하나의 엔티티 매니저 팩토리에서 다수의 엔티티 매니저를 생성하고 엔티티 매니저들은 DBCP에 있는 커넥션을 얻어서 DB와 통신한다.

하이버네이트를 포함한 JPA 구현체들은 EntityManagerFactory를 생성할 때 커넥션 풀도 만드는데 이것은 J2SE 환경에서 사용하는 방법이다. J2EE 환경에서는 컨테이너가 제공하는 데이터 소스를 사용하게 된다.

영속성 콘텍스트

영속성 콘텍스트는 "엔티티를 영구 저장하는 환경"이라는 뜻으로 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 연속성 콘텍스트에 엔티티를 보관하고 관리한다.

em.persist(member);

영속성 생명 주기

1. 비영속(new/transient): 비영속 상태는 영속성 콘텍스트와 전혀 관계가 없는 새로운 상태

@SpringBootTest
@Transactional
class MemberTest {

    @Autowired
    EntityManager em;

    @Test
    public void 엔티티_생명주기_비영속(){
        Member member = Member.of(1L, "hello jpa#1");
    }
}

2. 영속(managed) : 영속성 콘텍스트에 관리되는 상태

@SpringBootTest
@Transactional
class MemberTest {

    @Autowired
    EntityManager em;

   @Test
    public void 엔티티_생명주기_영속(){
        Member member = Member.of(1L, "hello jpa#1");
        em.persist(member);
    }
}

3. 준영속(detached) : 영속성 콘텍스트에 저장되었다가 분리된 상태

@SpringBootTest
@Transactional
class MemberTest {

    @Autowired
    EntityManager em;

   @Test
    public void 엔티티_생명주기_준영속(){
        Member member = Member.of(1L, "hello jpa#1");
        em.persist(member);

        em.detach(member);
    }
}

4. 삭제(removed): 삭제된 상태

@SpringBootTest
@Transactional
class MemberTest {

    @Autowired
    EntityManager em;

    @Test
    public void 엔티티_생명주기_삭제(){
        Member member = Member.of(1L, "hello jpa#1");
        em.persist(member);

        em.remove(member);
    }
}

영속성 콘텍스트 특징

1차 캐시

영속성 콘텍스트는 내부에 캐시를 가지고 있는데 이것을 1차 캐시라고 한다. 쉽게 이야기하면 영속성 콘텍스트 내부에 Map이 하나 있는데 Key는 식별자는 @Id로 매핑한 컬럼이고 Value는 엔티티 인스턴스이다.

JPA에서는 영속화하거나 조회할 때 엔티티를 1차 캐시에 저장한다.

1차 캐시는 동일한 트랜잭션에서 같은 영속성 컨텍스를 관리하는 구조이므로, 성능상 큰 이점은 없지만 영속성 컨텍스트 동작원리(메커니즘)를 이해하므로 얻을 수 있는 이점이 생기게 된다.

먼저 Member 엔티티는 다음과 같이 구성하였다. @GeneratedValue의 strategy는 기본값인 Auto를 사용하였다.

아래 테스트 코드를 보면 member 엔티티를 persist 한 후 em.find로 엔티티를 조회해 오면 쿼리가 나가지 않음을 알 수 있다.

그 이유는 member 엔티티를 persist 할 때 영속성 콘텍스트 내부의 1차 캐시에 저장하므로 DB에 조회를 하지 않아도 해당 엔티티 인스턴스를 가져올 수 있기 때문이다.

실행 결과를 보면 재밌는 것이 발견할 수 있는데 persist 할 때 쿼리가 나가지 않고 em.find()로 조회하기 전에 insert 쿼리가 나가는 것을 알 수 있다. 그렇다면 무조건 commit 하거나 flush 할 때만 나가는 게 아니라 상황에 맞게 나가는 건가?

혹시 @GeneratedValue 전략을 바꾼다면 어떻게 될까?라는 궁금증에 strategy를 Auto -> Identity로 변경해 보았다.

@GeneratedValue (strategy = AUTO -> IDENTITY)로 변경

아까와는 다르게 persist 할 때 insert 쿼리가 나가는 것을 볼 수 있다. 그렇다면 @GeneratedValue 전략에 따라 하이버네이트의 persist 동작 시점이 달라질 수 있다는 것을 알 수 있게 된다.

@GeneratedValue 전략이 IDENTITY일때 INSERT 쿼리가 나가는 이유

JPA의 영속성 컨텍스트 내부 1차 캐시는 KEY, VALUE 형태로 엔티티를 저장하는데, 이때 엔티티의 pk 값이 KEY가 됩니다. 즉 여기서는 Member.id가 KEY로 저장된다.

em.persist()로 엔티티 영속화하면 내부 1차 캐시에 저장되어야 하는데, IDENTITY 전략은 id 생성을 DB에 위임하기 때문에 DB에 실제 INSERT 쿼리가 나가야 ID 값을 알 수 있게 되므로(IDENTITY 전략은 AUTO_INCREMENT로 동작한다)

따라서 영속성 컨텍스트에 영속화하여 관리하기 위해 ID값을 알아야 하므로 즉시 INSERT 쿼리가 나간다

@GeneratedValue 전략이 AUTO일때 INSERT 쿼리가 안 나가는 이유

AUTO 전략은 @GeneratedValue의 기본값으로 DB에 따라 (TABLE, IDENTITY, SEQUENCE) 세 개 중 하나가 자동으로 지정됩니다. (MYSQL = IDENTITY, H2=SEQUENCE 등.., 아래그림 참고)

H2 DB를 사용중이므로 em.persist()로 엔티티를 영속화할 때 id 생성을 위해서 DB가 관리하는 SEQUENCE OBJECT에서 id 값을 가져와서 영속화가 가능하기 때문에 INSERT 쿼리가 나가지 않아도 알 수 있다.