[Spring] JPA, 영속성 컨텍스트, 1차 캐시, 쓰기 지연 📙
영속성 컨텍스트
-
애플리케이션과 데이터베이스 사이에서 객체를 보관하는 논리적 개념
-
EntityManager를 통해서 영속성 컨텍스트에 접근
- EntityManager가 생성되면 논리적 개념인 영속성 컨텍스트(PersistenceContext)가 1:1 생성
영속성 컨텍스트 이점
1. 1차 캐시 / 엔티티 동일성 보장
-
영속성 컨텍스트는 내부에 캐시를 갖고 있고, (id, instance)의 맵 형태로 엔티티들이 저장된다.
- 트랜잭션 단위의 굉장히 짧은 메모리 공간
이미지를 참고하자.

- em.persist(member)로 member가 영속성 컨텍스트에 영속되면, 1차 캐시는 이를 담는다.
- 이후 조회 시, DB에 바로 접근하는 것이 아닌 1차 캐시에 먼저 접근해 member1을 바로 찾고, 캐시에 없다면 DB에서 검색 후 해당 객체를 1차 캐시에 저장하고 반환한다.
- 1차 캐시를 거친 조회로 엔티티의 동일성 보장이 가능하다.
2. 트랜잭션을 지원하는 쓰기 지연
transaction.begin();
em.persist(memberA);
em.persist(memberB);
// ---- 1 ----
em.flush();
// ---- 2 ----
transaction.commit();
1의 영역에서 바로 INSERT QUERY를 DB에 바로 보낼 것 같다.
하지만 sql 쿼리를 바로 전송하거나 나중으로 지연 시킬 수 있다
- 쓰기 지연 SQL 버퍼에 쿼리를 담아뒀다가, 영속성 컨텍스트의 명령에 따라 DB에 전송되기 때문이다.

memberA가 컨텍스트에 영속되면, 우선 1차 캐시로 저장되고 쿼리는 SQL 버퍼에 넣어진다.
memberB도 똑같이 1차 캐시로 저장되고 쿼리는 SQL 버퍼에 넣어진다.

이후, transaction을 commit 또는 컨텍스트에 버퍼를 비우도록 명령(flush)하면, 버퍼의 쿼리가 DB에 넘어간다.
Author And Source
이 문제에 관하여([Spring] JPA, 영속성 컨텍스트, 1차 캐시, 쓰기 지연 📙), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@daydream/Spring-JPA-영속성-컨텍스트-1차-캐시-쓰기-지연저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)