영속성 컨텍스트2

영속성 컨텍스트2

1. 엔티티 조회, 1차캐시

​ 영속성 컨텍스트(entityManager)는 1차캐시를 들고있습니다.

• @Id 는 해당 Table의 PK가 됩니다.
• @Entity는 해당 객체자체가 됩니다 (ex: member)

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

// 1차 캐시에 저장됨
em.persist(member);

// 1차 캐시에서 조회
    Member findMember = em.find(Member.class, "member1");

member객체를 저장하면 캐시로 인해 조회가 가능합니다.

em.find를 통해 조회를 하려고하면 JPA는 영속성컨텍스트에서 DB를 보는게 아니라 1차캐시를 먼저 조회합니다.

 

 

 

만약 1차캐시에 없다는 DB에 조회를 합니다. (영한님 나와버렸네요..ㅈㅅㅠ)

Member findMember2 = em.find(Member.class, "member2");

하지만 트랜잭션 단위로 진행되고 소멸되기에

고객의 요청이 들어오면 entityManager은 생성되었다가 요청이끝나면 삭제되기에 큰 성능이점은 없다.

아래 그림과 같이 findMember2 조회 시 쿼리가 돌지 않았다 (쿼리가 한번만 돌았다.)

2. 영속 엔티티의 동일성을 보장한다.

​ - 마치 자바 컬렉션의 똑같은 객체가 있는것처럼 객체가 같다고 보장해준다.

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

// true
System.out.println(a==b);

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

3. 엔티티 등록 시 트랜잭션을 지원하는 쓰기 지연

em.getTransaction().begin(); // [트랜잭션 시작]

em.persist(memberA);
em.persist(memberB);

em.getTransaction().commit(); // [트랜잭션 커밋]

영속성 컨텍스트는 1차캐시뿐만아니라 쓰기지연SQL이 존재

memberA가 1차캐시에 들어감과 동시에

JPA는 쓰기지연SQL에 SQL INSERT 쿼리문을 만들어 쌓아둔다.

하여 트랜잭션 COMMIT하는 시점에 QUERY가 날라간다.

4. 엔티티 수정 및 변경 감지할 수 있다.

1. 커밋 감지되면 flush가 호출된다.

2. 스냅샷은 값을 읽어왔던 (find) 그래서 1차캐시에 들어왔던 상태를 캡쳐해두는데

커밋하는 시점에 JPA는 스냅샷을 일일히 비교하여 

3. **쓰기지연SQL저장소**에 UPDATE QUERY문을 저장한다.

4. , 5. 커밋을 때린다.