영속성 컨텍스트 2

엔티티 조회, 1차 캐시

※ 사실상 1차 캐시를 영속성 컨텍스트라 이해해도 됨

※ 현업에서는 크게 도움 되지 않음. 성능보다는 객체지향적으로 설계하는 데 있어서 의미가 있다.

 

데이터 베이스에서 조회할 때의 과정

1. find("member2") : 1차 캐시에 없음

2. DB 조회

3. 1차 캐시에 저장

4. 반환

5. 두 번째 조회

6. 캐시에 있는 member2 반환

 

영속 엔티티의 동일성 보장

다음과 같은 상황을 보자

...
try {
	Member findMember1 = em.find(Member.class, 101L);
    Member findMember2 = em.find(member.class, 101L);
    
    System.out.println(a == b);
    
    }
...

 

결과

true

 

JPA에서 같은 트렌잭션이면 "true"를 반환한다.

 

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

EntityManager em = emf.createEntityManager();
EintityTransaction transaction = em.getTransaction();

transaction.begin();

em.persist(memberA);
em.persist(memberB);
// 여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.

// 커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit();

 

내부적으로는 어떻게 동작하는가?

쓰기 지연 SQL 저장소가 존재 :

em.persist(memberA);

 

JPA가 엔티티를 분석해서 INSERT QUERY를 생성함 -> 쓰기 지연 SQL 저장소에 저장

em.persist(memberB);

마찬가지로 쓰기 지연 SQL 저장소에 저장

 

transaction.commit();

위 코드가 실행되는 순간 DB에 날라감.

 

굳이 이렇게 하는 이유?

이렇게 하면 '버퍼링'이라는 기술을 쓸 수 있음.

member1, member2에 데이터가 쌓였다 -> 한번에 이들을 보낼 수 있음

 

옵션 하나로 기본적으로 성능을 먹고 들어갈 수 있다!

 

엔티티 수정

데이터를 찾아오기 -> 값 변경

Member member = em.find(Member.cclass, 150L);
member.setName("ZZZZZ");

 

분명 찾아오고 값만 변경했을 뿐인데 값이 바뀌게 된다.

em.update(member) <- 이런 코드가 있어야 하는 것 아닌가?

 

변경 감지

1. flush()

2. 엔티티와 스냅샷 비교 -> 변경 감지

3. UPDATE SQL 생성

4. 쓰기 지연 SQL 저장소에 저장

5. flush

6. commit

 

엔티티 삭제

commit 시점에 삭제됨

 

JPA는 값을 바꾸면 transaction이 커밋되는 시점에 바꾸게 된다. 따라서 다음과 같은 코드를 짜면 안된다.

if (member.getName().equals("ZZZZZ")) {
	em.update(member);
}