영속성 컨텍스트, 1차캐시, 변경감지

• 영속성 컨텍스트란?

- "엔티티를 영구 저장하는 환경"이라는 뜻이다.

 

ex)

em.persist(member)

 

EntityManagerFactory를 통해 고객의 요청이 올 때마다 EntityManager를 생성하고, 새로운 고객 요청 시 또 다른 엔티티 매니저를 생성하고 엔티티 매니저는 내부적으로 데이터베이스 커넥션을 사용하여 DB를 사용하게 된다.

 

- EntityManager는 DB에 저장하는 것이 아닌 엔티티 매니저를 통해 영속성 컨텍스트에 접근하는 것이다.

 

- 실제로 DB에 쿼리가 날아가는 시점은 persist시점이 아닌 트랜잭션이 commit 된 시점이다.

 

         	//비영속
            Member member = new Member();
            member.setId(10L);
            member.setName("member1");

            //영속
            em.persist(member);

            //실제 쿼리가 날라가는 시점
            tx.commit();

 

 

• 비영속

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

//객체를 생성만 한 상태

 

 

• 영속 

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

//객체를 생성한 후 em.persist(member)로 저장한 상태

 

 

• 준영속

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

//em.detach(member) 영속이 분리된 상태

 

 

• 삭제

- 삭제된 상태

//em.remove(member) 영구 저장한 데이터베이스를 지우는 상태

 

 

 

---

 

 

 

영속성 컨텍스트의 이점

• 1차 캐시
• 동일성 보장
• 트랜잭션을 지원하는 쓰기 지연
• 변경 감지
• 지연 로딩

 

 

여기서 member.setId("member1") 이 부분이 Key가 되고 member 객체 자체가 Value가 된다.

 

• 1차 캐시란?

DB 트랜잭션 안에서만 돌게 되는 것이다.

 

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

 

em.find(Member.class, 10L)  //1차 캐시에서 조회

 

find로 1차 캐시에서 찾고 없으면 DB에서 조회하여 반환하게 된다.

 

 

 

 

 

위의 코드와 같이 같은 트랜잭션 내에서 조회하게 될 경우 DB에서 조회가 아닌 1차캐시에서 조회하게 되어 아래와 같이 SELECT쿼리가 나가지 않는다.

 

 

결과

 

 

---

 

 

• 만약  같은 키의 값을 2번 조회하게 될 경우 어떻게 될까??

아래 코드와 같이 첫 번째 조회(findMember1)에서는 DB에서 조회하게 되고, 두 번째 조회(findMember2)에서는 DB에서 가져온 1차 캐시를 조회하게 되어 SELECT 쿼리는 한 번만 나가게 된다.

 

 

조회

 

 

 

결과

 

 

 

---

 

 

• 영속 엔티티의 동일성 보장

 

            Member findMember1 = em.find(Member.class, 10L);
            Member findMember2 = em.find(Member.class, 10L);

            System.out.println("findMember = " + (findMember1 == findMember2));

 

 

 

위의 코드와 같이 JPA는 영속 엔티티의 동일성을 보장하여 같은 트랜잭션 안에서 == 비교를 하여도 동일한 참조가 나오게 되어 true가 반환되었다.

 

 

 

 

---

 

 

• 엔티티 수정 변경 감지

 

 

위의 코드에서 객체를 생성하고, 저장 후 commit까지 하여 저장하였다.

 

 

 

그 후 11L을 조회하여 setName으로 Name을 변경하였다. 여기서 유의해야 하는 게 JPA는 자바 컬렉션을 다루듯이 변경하고,             em.persist(member)를 할 필요가 없다는 것이다.

 

 

 

 

 

위의 결과처럼 em.find로 select 쿼리가 한 번 나가게 되고, member.setName으로 update 쿼리 한 번이 나가게 된 것을 볼 수 있다.

 

실제로 DB에 반영

 

• JPA는 변경 감지(Drity Checking) 기능으로 엔티티를 변경할 수 있는 기능을 제공한다.

 

JPA는 commit을 하게 되면 엔티티와 스냅샷을 비교한다.

 

• 스냅샷이란?

 

값을 읽어온 최초 상태를 스냅샷이라고 하는데, 엔티티가 변경됐을 경우, update쿼리를 쓰기 지연 sql저장소에 저장한 후 update쿼리를 DB에 전달하게 된다.

 

 

 

 

---

 

 

출처 : https://www.inflearn.com/course/ORM-JPA-Basic#