연속성 컨텍스트

Entity를 영구 저장하는 환경

 

엔티티의 생명주기

- 비영속

: 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태

- 영속

: 영속성 컨텍스트에 관리되는 상태

- 준영속

: 영속성 컨텍스트에 저장되었다가 분리된 상태

- 삭제

 

 

---

영속성 컨텍스트의 이점

- 1차 캐시

: 영속 컨텍스트에 pk로 지정한 id 값이 엔터티와 함께 key와 value로 저장되어 있다.

JPA의 Find~~ 는 모두 영속성 컨텍스트에서 1차 캐시로 엔터티를 갖고오는 것이다.

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

// 엔티티 영속
em.persist(member)

단, 1차 캐시는 하나의 트랜잭션 안에서 발생하는 캐시이다.

전체가 다 사용하는 캐시는 2차 캐시이므로 전체가 사용하는 캐시는 아니다. 따라서 성능의 이점이 크지는 않다.

 

- 동일성 보장

: 1차 캐시로 반복 가능한 읽기 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 어플리케이션 차원에서 제공

 

- 트랙잭션을 지원하는 쓰기 지연

Member member1 = new Member(150L, "member1");
Member member2 = new Member(160L, "member2");
em.persist(member1);
em.persist(member2);
transaction.commit();

JPA는 persist영속성 컨텍스트로 들어가 있는 상태에서는 DB로 데이터를 바로 넣지 않는다.

Transaction이 일어나야 db에 쿼리문을 날려 데이터를 넣는다.

persist 가 일어나면 쓰기 지연이 일어 나는데 버퍼링 같은 것으로 날려지는 트렌젝션이 몇 개 이상 모아졌을 때 db에 던지도록 한다. 이 때 사용되는 것이 JPA의 Batch Size 이다.

 

- 변경 감지(엔터티 수정)

JPA에서 엔티티를 수정하게 되면 어떤 매커니즘으로 이루어지는 건가?

엔터티를 수정하기 위해 DB에서 엔티트를 가져올 때 1차 캐시에 스냅샵으로 해당 엔티티를 저장해 놓는다.

후에 엔터티를 변경하였을 때 스냅샵에 있는 기존의 엔티티와 비교를 하여 엔티티가 변경 되면 Flush 과정을 거치며 해당 update 쿼리문을 db에 날려 데이터를 수정한다.

---

- Flush

수정, 삭제 등 변경 감지 시 작동한다.

수정된 엔티티 쓰기 지연 sql 저장소에 등록한다.

쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송

 

영속성 컨테스트를 flush 하는 방법

• em.flush() - 직접 호출
• 트랜잭션 커밋 - 플러시 자동 호출
• JPQL 쿼리 실행 - 플러시 자동 호출

 

flush 특징

• 영속성 컨텍스트를 비우지 않음 -> 1차 캐시에 그대로 들어있음
• 영속성 컨텍스트의 변경내용을 데이터베이스에 동기화
• 트랜잭션이라는 작업 단위가 중요 -> 커밋 직전에만 동기화
하면 됨

---