JPA 영속성 컨텍스트

zwon·2023년 9월 27일
0

JPA

목록 보기
4/9

JPA의 영속성 컨텍스트는 중요한 개념이기때문에 이해를 무조건 해야한다.

영속성 컨텍스트

  • 엔티티를 영구 저장하는 환경
  • EntityManager.persist()를 통해 엔티티를 영속성 컨텍스트에 저장
  • EntityManager를 통해서 영속성 컨텍스트에 접근하는 것
  • EntityManager 안에 눈에 보이지 않는 영속성 컨텍스트가 생간다고 생각.

엔티티의 생명주기

비영속 new/transient

  • 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
  • 객체를 생성한 상태
// 객체 생성 = 비영속
Member member = new Member();
member.setId("member1");
member.setName("회원1")

영속 managed

  • 영속성 컨텍스트에 관리되는 상태
  • 참고로 persist()한다고 DB에 저장되는것이 아님.
// 객체 생성 = 비영속
Member member = new Member();
member.setId("member1");
member.setName("회원1")

// emf는 EntityManagerFactory
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

// 객체를 저장한 상테 = 영속
em.persist(member);

준영속 detached

  • 영속성 컨텍스트에 저장되었다가 분리된 상태, 영속 -> 준영속
  • 영속성 컨텍스트가 제공하는 기능을 사용하지 못함.
// member 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
// 특정 엔티티만 준영속 상태로 전환
em.detach(member);

// 영속성 컨텍스트를 완전히 초기화
em.clear();

//영속성 컨텍스트를 종료
em.close();

삭제 removed

  • 삭제된 상태
  • 실제 DB 삭제를 요청
// member 엔티티를 삭제한 상태
em.remove(member)

그러면 이렇게 영속성 컨텍스트를 중간에 둠으로써 얻는 이점은 무엇이 있을까?

1차 캐시

  • 영속성 컨텍스트는 내부에 1차 캐시라는 것을 가지고 있다.
  • 다음과 같은 코드를 실행했다고 하자.
// 객체 생성 = 비영속
Member member = new Member();
member.setId("member1");
member.setName("member")

em.persist(member)
  • 그러면 영속성 컨텍스트엔 다음과 같이 1차 캐시에 저장된다.
  • 이렇게 저장되어있는상태에서 조회를 한다면,
// 객체 생성 = 비영속
Member member = new Member();
member.setId("member1");
member.setName("member")

em.persist(member)

// member1 조회
Member findMem = em.find(Member.class, "member1");
  • DB에 쿼리문을 날려 조회하는 것이 아니라 먼저 영속성 컨텍스트에서 member1에 대한 엔티티를 조회한다. 결과값이 있으면 그 결과값을 그냥 조회한다.
  • 근데 만약 member2를 조회한다고 하면 1차 캐시에 member2가 존재하지 않으니 이때는 DB에서 조회를 한다.
// member2 조회
Member findMem = em.find(Member.class, "member2");
  • DB에 조회를 하면서 1차 캐시에 member2를 저장한다.

  • 사실 영속성 컨텍스트는 보통 DB의 한 트랜잭션이 끝날 때 같이 종료시키기때문에 성능상 이점이 아주 크지는 않는다. 트랜잭션을 종료하면서 1차 캐시도 날라간다.
  • 이렇게 하나의 트랜잭션 안에서 member1을 조회한 값을 == 비교를 하면 true가 나온다. 즉, JPA는 영속 엔티티의 동일성을 보장해준다.
Member findMem1 = em.find(Member.class, "member1");
Member findMem2 = em.find(Member.class, "member1");

// 결과 
findMem1 == findMem2 결과 : true

쓰기지연

  • 영속성 컨텍스트는 엔티티를 DB에 등록할 때 쓰기 지연 기능을 제공한다.
  • persist(...)하면 1차 캐시에 저장하는 것 뿐만 아니라 "쓰기 지연 SQL 저장소"에 엔티티를 분석해서 SQL INSERT문을 생성하고 저장한다.
  • commint()할 때까지 JPA는 SQL을 DB에 날리지 않고 쓰기 지연 SQL 저장소에 쌓아놓고있는고 commit()하는 순간 쿼리문을 날리기때문에 이러한 것을 쓰기 지연이라고 한다.
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();

em.persist(MemberA);
em.persist(MemberB);
// persist()는 sql문을 DB에 날리지 않는다.

// commit()하는 순간 DB에 쿼리문을 날린다.
tx.commit();

변경 감지

  • member의 정보를 수정한다고 가정하자
// 영속 엔티티 조회
Member member = em.find(Member.class, 1L);
// 영속 엔티티 데이터 수정
member.setName("Spring");
...
transaction.commit();
  • JPA 목적은 객체를 JAVA 컬렉션 다루듯이 객체를 다루는 것이라고 했다.
  • 그래서 member.setName(...)을 한 다음에 em.persist(Member)나 em.update(..)를 해주지 않아도 된다.
  • 그냥 변경할 객체를 찾아오고 수정하면 된다.

이유

  • JPA는 commit을 하는 시점에 내부적으로 flush()를 호출한다.
  • 플러시 설명 추가
  • 그리고 엔티티랑 스냅샷을 비교한 다음 바뀐 값이 있으면 UPDATE SQL을 쓰기 지연 SQL 저장소에 만들어놓는다.
    • 스냅셧 : 값을 읽어온 최초의 시점의 상태
  • 그 다음 UPDATE쿼리를 DB에 날리고 commit한다.

flush()

  • 영속성 컨텍스트의 변경내용을 DB에 반영하는 것
  • 쓰기 지연 SQL 저장소에 등록된 쿼리를 DB로 전송하는 것으로 생각하면된다.
  • flush()가 발생되면,
    • 엔티티와 스냅샷 비교 후 변경된 것에 대한 SQL 생성
    • 생성된 SQL을 쓰기 지연 SQL 저장소에 등록
    • 쓰기 지연 SQL 저장소에 등록된 쿼리를 DB에 전송

flush() 방법

// 직접 호출
em.flush()

// commit() 시점에 자동으로 flush 호출
transaction.commit()

// flush() 자동 호출
JPQL 쿼리 실행

flush() 모드

// 커밋이나 쿼리를 실행할 때 플러시 (defalut값)
em.setFlushMode(FlushModeType.AUTO);

// 커밋할 때만 플러시
em.setFlushMode(FlushModeType.COMMIT);

자바 ORM 표준 JPA 프로그래밍-기본편을 학습하면서 정리한 블로그입니다.

profile
Backend 관련 지식을 정리하는 Back과사전

0개의 댓글