JPA 영속성 관리

3 minute read

이번 블로깅에서는 JPA가 내부적으로 어떻게 동작하는지 작성할 것이다.

Step 1: 영속성 컨텍스트

  • JPA를 이해하는데 가장 중요한 용어
  • Entity를 영구 저장하는 환경 이라는 뜻
  • EntitiyManager.persist(entity);
    • 사실 이건 디비에 저장하는게 아니라 entity를 영속성 컨텍스트라는 곳에 저장하는 것이다.
    • 밑에서 보면 알겠지만 트랜잭션이 커밋이되어야 디비에 저장된다.
  • 영속성 컨텍스트라는 것은 논리적인 개념으로서 눈에 보이지 않으며, EntityManager를 통해서 영속성 콘텍스트에 접근한다.

Step 2: Entity의 생명주기

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

      //객체를 생성한 상태(비영속) - JPA랑 전혀 상관이 없다.
      Member member = new Member();
      member.setId("member1");
      member.setUsername("회원1");
      
  • 영속 (managed)
    • 영속성 컨텍스트에 관리되는 상태

      //객체를 생성한 상태(비영속) - JPA랑 전혀 상관이 없다.
      Member member = new Member();
      member.setId("member1");
      member.setUsername("회원1");
          
      EntityManagerFactory emf = Persistence.createEntityManager("hello");
      EntityManager em = emf.createEntityManager();
      EntityTransaction tx = em.getTransaction();
      tx.begin();
      try {
          여기서부터 JPA랑 관련이 있음.
          //객체를 저장한 상태 (영속)
          em.persist(member); -> 여기선 디비에 저장되지 않음.
              
          entityManager안의 영속성 컨텍스트에서 member를 관리하기 시작한다.
              
          tx.commit(); -> 이때 디비에 저장이된다.
          }
      catch (Exception ex){
      	tx.rollback();
      }
          
          
      

      image-20211017213038342

  • 준영속 (detached)
    • 영속성 컨텍스트에 저장되었다가 분리된 상태
    • em.detach(member);
  • 삭제 (removed)
    • 삭제된 상태
    • em.remove(member); -> 영속성 컨텍스트 뿐만아니라, 디비에서 실제 데이터까지 지움.

Step 3: JPA Request FLOW

  • 고객이 요청을 할 때 마다 EntityManager Factory를 통해서 EntityManager를 생성한다.

  • 생성된 EntityManager는 내부적으로 Database Connection pool을 사용해서 DB를 사용하게 된다.

image-20211017211422209

Step 4: 영속성 컨텍스트의 이점

  • 1차 캐시
//entity를 생성한 상태 (비영속)
Member member1 = new Member();
member1.setId("member1");
member1.setUsername("회원1");

//entity를 영속 -> 1차 캐시에 저장됨
em.persist(member1);

//1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");

Member findMember2 = em.find(Member.class, "member2");

만약 캐시에 값이 있다면 캐시에서 값을 가져오고, 캐시에 값이 없다면 DB에서 가져온다.

image-20211017222308364

  • 동일성(identity) 보장
    • 1차 캐시로 반복 가능한 읽기 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공 [자바 컬렉션에서 꺼냈을때 처럼 같은 객체로 인지한다.]

       Member a = em.find(Member.class, "member1");
       Member b = em.find(Member.class, "member1");
           
       System.out.println(a==b); // 동일성 비교 true
      
  • 트랜잭션을 지원하는 쓰기 지연 (transactional write-behind)
    • 첫 번째 persist시에 1차캐시에 memberA가 저장되고, 쓰기지연 sql 저장소에 INSERT memberA 쿼리가 저장된다.
    • 두 번째 persist시에 1차 캐시에 memberB가 저장되고, 쓰기지연 sql 저장소에 INSERT memberB 쿼리가 저장된다.
    • 트랜잭션 커밋 시 쓰기지연 sql저장소에 있던 INSERT 쿼리들이 실행되어 DB에 데이터가 저장된다.
    EntityManager em = emf.createManager();
    EntityTransaction transaction = em.getTransaction();
    //엔티티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다.
      
    transaction.begin();
      
    em.persist(memberA);
    em.persist(memberB);
    //여기 까지 INSERT SQL을 데이터베이스에 보내지 않는다.
      
    //커밋 하는 순간 데이터베이스에 INSERT SQL을 보낸다.
    transaction.commit();
    
  • 변경 감지(Dirty Checking)
이전 블로그에서도 이 내용이 포함되어있는데 JPA는 특히나 이 부분이 재미있다.

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

transaction.begin();

//영속 엔티티 조회
Member memberA = em.find(Member.class,"memberA");

//영속 엔티티 데이터 수정
memberA.setUserName("hi");
memberA.setAge(10);

이쯤에서 뭔가 em.persist나 em.update가 나와야할 것 같은데 없어도 수정이 된다 ㅋㅋ.
jpa의 목적이 자바 컬렉션 다루듯이 객체를 다루는 것이라 
컬렉션을 잘 생각해보면 컬렉션에서도 데이터를 가져온 후 수정 하면 별도로 값을 넣지 않아도 수정이 된다.

transcation.commit();

image-20211017225754483

여기서 스냅샷이란 영속성 컨텍스트에서 1차캐시에 최초에 들어온 상태를 말한다.

  • 지연 로딩(Lazy Loading)

Step 5: 플러시

플러시란 영속성 컨텍스트의 변경내용을 데이터베이스에 반영하는 작업이다.

하지만 영속성 컨텍스트를 비우지 않으며, 트랜잭션이라는 작업 단위가 중요하므로 커밋 직전에만 동기화 하면 된다.


플러시가 발생하면 무슨 일이 생길까? -> 데이터베이스 트랜잭션이 커밋되면 플러시가 자동으로 발생한다고 보면된다.

  • 변경 감지 ( dirty checking )
  • 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
  • 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송 (등록, 수정, 삭제 쿼리)


영속성 컨텍스트를 플러시하는 방법

  • em.flush() - 직접 호출
  • 트랜잭션 커밋 - 플러시 자동 호출
  • JPQL 쿼리 실행 - 플러시 자동 호출
JPQL 쿼리 실행 시에 플러시가 자동으로 호출되는 이유

em.persist(memberA);
em.persist(memberB);

//중간에 JPQL 실행
query = em.createQuery("select m from Member m", Member.class);
List<Member> members = query.getResultLists();


중간에 JPQL을 실행 할 시점에는 커밋 된 데이터가 없어 원래대로라면 SELECT 결과는 없어야한다.
하지만 이런 문제를 방지하고자 JPQL에서는 자동으로 쿼리 실행전 플러시를 해버린다.
즉, 플러시 후 SELECT 쿼리가 실행 되기 때문에 memberA, memberB 데이터가 담긴다.

Step 6: 준영속 상태

  • 영속 -> 준영속
  • 영속 상태의 엔티티가 영속성 컨텍스트에서 분리 (detached)
  • 영속성 컨텍스트가 제공하는 기능을 사용 못함.
참조 - 자바 ORM 표준 JPA 프로그래밍 By 김영한

Categories:

Updated:

Comments