엔티티 조회, 1차 캐시

• em.persist(member); 를 할 경우 위 그림처럼 1차 캐시에 저장되는 것이다.

1차 캐시에서 조회

Member findMember = em.find(Member.class, "member1");

• 조회를 할 경우, 영속성 컨텍스트에서 1차 캐시에서 조회를 해보고, 없을 경우 DB에 접근한다.
  바로 DB에 접근하는 것이 아니다!! (SELECT 쿼리가 안나간 것으로 확인 가능)
  -> 한 트랜잭션 내에서 효과가 있다!

영속 엔티티의 동일성 보장

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
System.out.println(a==b); // 결과 : True

• 1차 캐시에서 조회를 했기 때문이다.

엔티티 등록

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

• persist()는 DB에 INSERT SQL를 보내는 것이 아닌, commit()을 하는 순간 DB에 INSERT SQL을 보낸다.

• persist()를 할 경우, 쓰기 지연 SQL 저장소에 SQL을 작성해서 보관해둔다.

• 트랜잭션을 commit()할 때, 보관해둔 SQL을 DB에 보낸다.

이점

• hibernate.jdbc.batch_size와 같이 SQL을 모아서 한번에 DB에 보내는 버퍼링 기능을 사용할 수 있다.

엔티티 수정

변경 감지

Member member = em.find(Member.class,150L); // 엔티티 조회
member.setName("ZZZZZ"); // 멤버의 이름을 바꾼다.

• 객체의 이름을 바꾼 것 만으로 수정이 되며, persist()를 할 필요 없다.

• em.update()와 같은 코드가 필요할 것 같지만 아니다!

• 엔티티를 처음 읽어온 시점(1차 캐시에 들어온 시점)의 스냅샷을 떠둔다.

• 엔티티의 값을 변경하고 커밋하는 시점에 내부에서 flush()가 호출되어 엔티티와 스냅샷을 비교하여
  최초 시점과 값이 변경되었을경우 UPDATE SQL을 DB에 보낸다.

플러시

영속성 컨텍스트의 변경 내용을 DB에 반영하는 것

플러시가 발생할 경우

• 변경 감지(스냅샷 비교)

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

• 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송(등록,수정,삭제 쿼리)

영속성 컨텍스트를 플러시하는 방법

• em.flush()

• 트랜잭션 커밋

• JPQL 쿼리 실행

플러시는!

• 영속성 컨텍스트를 비우는 것이 아니다.

• 변경 내용을 DB에 동기화하는 것

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

준영속 상태

• 영속 -> 준영속

• 영속 상태의 엔티티가 영속성 컨텍스트에서 분리 된 상태(detached)

• 영속성 컨텍스트가 제공하는 기능을 사용 못함(변경감지 등)

준영속 상태로 만드는 방법

• em.detach(entity) : 특정 엔티티만 준영속 상태로 전환

• em.clear() : 영속성 컨텍스트 완전 초기화

• em.close() : 영속성 컨텍스트를 종료