영속성 컨텍스트

  • 엔티티를 영구 저장하는 환경이라는 뜻
  • EntityManager.persist(entity) : 엔티티를 DB에 저장한다는 의미가 아니라 엔티티를 영속성 컨텍스트에 저장한다라는 의미
    • 영속성 컨텍스트는 눈에 보이지 않는 논리적인 개념
    • 엔티티 매니저를 통해 영속성 컨텍스트에 접근한다고 보면 된다.
    • EntityManager를 생성하면 1대1로 PersistenceContext가 생성된다. (엔티티 매니저 안에 영속성 컨텍스트가 있다고 생각면 된다.)
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

//비영속 상태 (new)
Member member = new Member();
member.setId(100L);
member.setName("Hello!!");

//영속 상태 (managed)
em.persist(member);

//준영속 상태 (detached)
em.detach(member);
  • 영속 상태 : 영속성 컨텍스트에 관리되는 상태. 영속 상태가 될 때 DB 쿼리가 보내지는 것은 아니다. 실제로는 트랜잭션을 커밋하는 시점에 영속성 컨텍스트에 있는 쿼리가 DB로 보내진다.
  • 준영속 상태 : 엔티티를 영속성 컨텍스트에서 지운다.

1차 캐시

Member member = new Member();  
member.setId("member1");  
member.setUsername("회원1"); 

//영속 상태 : 영속 컨텍스트의 1차 캐시에 저장된다.
em.persist(member);

//1차 캐시에 저장된 값을 조회하여 반환한다.
//그렇기 때문에 해당 쿼리가 DB로 보내지지 않는다.
Member findMember = em.find(Member.class, "member1");
//1차 캐시에 저장된 값이 있는 지 확인 후 없으면 DB에서 조회하여 1차 캐시에 저장한 후 반환한다.
Member findMember2 = em.find(Member.class, "member2");
  • 영속성 컨텍스트를 1차 캐시라고 보면 된다.
  • 여러 요청이 들어오면 각각의 1차 캐시가 생성된다.
  • 엔티티 매니저는 DB 트랜잭션 단위이기 때문에 트랜잭션이 종료되면 해당 영속 컨텍스트가 지워지므로 1차 캐시도 함께 날라간다. 즉, DB 트랜잭션 한 사이클 안에서만 이점을 얻을 수 있기 때문에 큰 효과를 느낄 수는 없다.
  • 성능적 이점보다는 좀 더 객체지향적으로 설계할 수 있다.

1차 캐시에서 조회1 1차 캐시에서 조회2

영속 엔티티의 동일성(identity) 보장

Member findMember1 = em.find(Member.class, 101L);
Member findMember2 = em.find(Member.class, 101L);
System.out.println(findMember1 == findMember2); //동일성 비교 true
  • 마치 자바 컬렉션에서 같은 레퍼런스의 객체를 비교할 때와 같다.

엔티티를 등록할 때 트랜잭션을 지원하는 쓰기 지연

EntityManager em = emf.createEntityManager(); 
EntityTransaction transaction = em.getTransaction(); 
transaction.begin();

em.persist(memberA); 
em.persist(memberB); 
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다. 

//커밋하는 순간 DB에 INSERT SQL을 보낸다.
transaction.commit(); //트랜잭션 커밋
  • em.persist(entity)가 호출될 때마다 엔티티가 1차 캐시에 저장됨과 동시에 INSERT SQL을 생성하여 쓰기 지연 SQL 저장소에 저장한다.
  • 트랜잭션 커밋 시점에 쓰기 지연 SQL 저장소에 저장되어있던 SQL들이 DB로 flush가 되면서 commit 한다.
  • 커밋 시점에 한 번에 SQL를 날리는 이 기능은 JPA 설정 파일의 옵션의 hibernate.jdbc.batch_size의 설정된 값만큼 모아서 DB로 보내고 커밋한다.
  • 특별한 배치 쿼리가 아닌 이상은 별 차이가 없다.

엔티티 수정 변경 감지(Dirty Checking)

Member member = em.find(Member.class, 150L);
member.setName("hi");

transaction.commit();
  • 마치 자바 컬렉션을 다루듯이 값을 변경하는 것처럼 값을 변경 후 em.persist(member)을 호출해서는 안 된다.

변경 감지

  • 스냅샷 : 최초로 영속 컨텍스트에 들어온 엔티티
  • 트랜잭션 커밋이 되면 변경된 엔티티와 스냅샷 엔티티를 전부 비교하여 변경된 엔티티가 있으면 UPDATE SQL을 생성하여 쓰기 지연 SQL 저장소에 저장하고 flush 후 commit 한다.

플러시(flush)

  • 영속성 컨텍스트의 변경 내용을 DB에 반영하는 것
  • 변경 감지, 수정된 엔티티 쓰기 지연 SQL 저장소에 등록, 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송한다.
  • 플러시하는 방법
    • em.flush()로 직접 호출한다. 주로 테스트할 때 쓴다.
      • 트랜잭션 커밋 전에 만나면 바로 DB에 쿼리가 반영이 되고 그 후에 커밋을 만나면 트랜잭션 커밋이 된다.
      • 트랜잭션 커밋을 만나기 전이기 때문에 이 시점에서는 트랜잭션이 종료되지 않았으므로 1차 캐시가 남아있는 상태이다.
    • 트랜잭션 커밋할 때 자동으로 호출된다.
    • JPQL 쿼리 실행 시 자동으로 호출된다.
  • 영속성 컨텍스트를 비우지 않는다.
  • 영속성 컨텍스트의 변경 내용을 DB에 동기화한다.
  • 결국 트랜잭션 작업 단위가 중요하기 때문에 커밋 직전에 동기화하면 된다.

준영속 상태

  • 영속 상태의 엔티티를 영속성 컨텍스트에서 분리한다.
  • 영속성 컨텍스트에 관리하는 엔티티가 없기 때문에 커밋을 만나도 변경 내용이 저장되지 않는다.
  • em.detach(entity) : 특정 엔티티만 준영속 상태로 전환할 때 사용
  • em.clear() : 엔티티 매니저 안의 영속성 컨텍스트를 완전히 초기화. 1차 캐시와 관계없이 테스트케이스를 작성하여 눈으로 보고 싶을 때 사용한다.
  • em.close() : 영속성 컨텍스트를 종료