애정코딩 💻

JPA에서 가장 중요한 2가지

- 객체와 관계형 데이터베이스 매핑하기

- 영속성 컨텍스트

영속성 컨텍스트가 뭘까?

JPA를 이해하는데 가장 중요한 용어이다. "엔티티를 영구 저장하는 환경"이라는 뜻. -> EntityManager.persist(entity);

- persist는 사실 DB에 저장하는게 아니고 Entity를 영속성 컨텍스트에 저장한다는 뜻이다.

- 논리적인 개념으로 눈에 보이지 않는다. EntityManager를 통해서 영속성 컨텍스트에 접근한다.

- 여러개의 EntityManager가 하나의 영속성 컨텍스트를 바라본다.

엔티티의 생명주기는 어떻게 될까?

비영속

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

영속

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

준영속

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

삭제

- 삭제된 상태

//객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("애정");

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

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

persist를 한다고 해서 DB에 쿼리가 날라가는게 아니고. 트렌젝션에 커밋하는순간에 날라간다.

왜이런 이상한 메커니즘을 사용할까?

영속성 컨텍스트를 이용해 아래와 같은 이점을 누린다.

- 1차 캐시

조회기능이 실행되었을 때 1차 캐시에서 먼저 조회한다. -> 없으면 DB에서 조회 -> 1차 캐시에 저장

쿼리를 저장하는게 아니고 해당 객체를 저장 즉 객체 저장한다 (1차 캐시에 저장)-> 바로 조회한다(1차 캐시에서 조회) 

- 동일성 보장

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

1차 캐시가 있음으로 인해 가능하다.

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

영속 컨텍스트 안에는 1차캐시, 쓰기 지연 SQL 저장소가 있다

persist가 되는 순간 1차캐시에 객체를 저장하고, 쓰기 지연 SQL 저장소에 쿼리를 저장한다.

-> transaction.commit(); 을 하는 순간 쓰기 지연 SQL 저장소 에서 flush를 하여 DB로 쿼리를 날린다.

- 변경 감지

1. 엔티티와 스탭샷 비교한다. -> 이 때 변경을 감지한다.

2. UPDATE SQL 생성 하여 쓰기 지연 SQL 저장소에 저장

- 지연 로딩

플러시

영속성 컨텍스트의 변경내용을 데이터베이스에 반영

영속성 컨텍스트를 비우지 않는다.

트랜잭션이라는 작업 단위가 중요 - 커밋 직전에만 동기화 하면 됨

플러시가 발생하면 무슨일이 생길까?

- 변경 감지

- 수정된 엔티티 쓰기 지연 SQL 저장소에 등록

- 트렌젝션 커밋이 되면 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송

어떻게 사용하나?

em.flush() - 직접 호출

트랜잭션 커밋 - 플러시 자동 호출

JPQL 쿼리 실행 - 플러시 자동 호출

 - 아래와 같이 persist를 하고 플러시가 되지 않는 상태에서 JPQL이 실행되면 조회가 안되니까(DB에 반영이 안되서) 

   이러한 문제점 때문에 JPA 쿼리가 실행될 때 자동으로 플러시를 호출한다.

준영속 상태

영속 -> 준영속

영속 상태의 엔티티가 영속성 컨텍스트에서 분리한다.

영속성 컨텍스트가 제공하는 기능을 사용 못한다.

어떻게 사용할까?

em.datach(entity) -> 특정 엔티티만 준영속 상태로 전환

em.clear() -> EntityManager 안에 있는 영속성 컨텍스트를 모두 지운다. (초기화)

em.close() -> 영속성 컨텍스트를 종료한다.