[Spring] Persistence Context: first-level cache

thingzoo·2023년 6월 26일
0

Spring

목록 보기
25/54
post-thumbnail

영속성 컨텍스트는 캐시를 통해 Entity 객체를 효율적으로 관리하고 있다.

first-level cache(1차 캐시)

  • 영속성 컨텍스트는 내부적으로 캐시 저장소를 가지고 있다.
    • Entity 객체들이 1차 캐시 즉, 캐시 저장소에 저장된다.
    • 캐시 저장소는 Map 자료구조 형태
      • key에는 @Id로 매핑한 기본 키 즉, 식별자 값 저장
      • value에는 해당 Entity 클래스의 객체 저장
  • 영속성 컨텍스트는 캐시 저장소 Key에 저장한 식별자값을 사용하여 Entity 객체를 구분하고 관리

ActionQueue(쓰기 지연 저장소)

  • JPA는 트랜잭션 처럼 SQL을 모아서 한번에 DB에 반영한다.
    • JPA는 이를 구현하기 위해 쓰기 지연 저장소를 만들어 SQL을 모아두고 있다가 트랜잭션 commit 후 한번에 DB에 반영한다.

예시

  • em > actionQueue > insertions > executables
    • Insert할 memo#2, memo#3 Entity 객체 2개가 들어가 있음

  • 트랜잭션 commit 후
    • actionQueue에 있던 insertions 데이터가 사라짐

flush()

  • em.flush();: 영속성 컨텍스트의 변경 내용들을 DB에 반영하는 역할 수행
    • 즉, 쓰기 지연 저장소의 SQL들을 DB에 요청하는 역할 수행
    • commit할때 자동으로 호출됨

Dirty Checking(변경 감지)

  • 영속성 컨텍스트에 저장된 Entity가 변경될 때마다 Update SQL이 쓰기 지연 저장소에 저장된다면?
    • 하나의 Update SQL로 처리할 수 있는 상황을 여러번 Update SQL을 요청하게 되기 때문에 비효율적
  • JPA는 영속성 컨텍스트에 Entity를 저장할 때 최초 상태(LoadedState)를 저장
    • 트랜잭션이 commit되고 em.flush(); 가 호출되면 Entity의 현재 상태(entityInstance)와 저장한 최초 상태(LoadedState)를 비교
    • 변경 내용이 있다면 Update SQL을 생성하여 쓰기 지연 저장소에 저장하고 모든 쓰기지연 저장소의 SQL을 DB에 요청
    • 마지막으로 DB의 트랜잭션이 commit 되면서 반영
  • 따라서 변경하고 싶은 데이터가 있다면, 먼저 데이터를 조회하고 해당 Entity 객체의 데이터를 변경하면 자동으로 Update SQL이 생성되고 DB에 반영됨
    • 이러한 과정을 변경 감지, Dirty Checking이라함!
profile
공부한 내용은 바로바로 기록하자!

0개의 댓글