3.4 영속성 컨텍스트의 특징

- 영속성 컨텍스트와 식별자 값

영속성 컨텍스트는 엔티티를 식별자 값(@Id로 테이블의 기본키와 매핑한 값)으로  구분한다.

따라서 영속 상태는 식별자 값이 반드시 있어야 한다. 식별자 값이 없으면 예외가 발생한다.

 

- 영속성 컨텍스트와 데이터 베이스 저장

영속성 컨텍스트에 있는 엔티티가 데이터 베이스에 저장되는 시점은 JPA가 트랜재션을 커밋하는 순간이다.

이를 플러시(flush)라고 한다.

 

- 영속성 컨텍스트가 엔티티를 관리하면 다음과 같은 장점이 있다.

- 1차캐시

- 동일성 보장

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

- 변경감지

- 지연로딩

 

3.4.1 엔티티 조회

영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이것을 1차 캐시라고 한다. 영속 상태의 엔티티는 모두 이곳에 저장된다. -> 영속성 컨텍스트에 Map이 하나 있는데, 키는 @Id로 매핑한 식별자고 값은 엔티티 인스턴스다.

//엔티티를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

em.persist(member);

-> 1차 캐시에 저장된 상태, 모든 식별자는 @Id로 매핑된 필드값

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

-> em.find()를 호출하면 먼저 1차 캐시에서 엔티티를 찾고 만약 찾는 엔티티가 1차 캐시에 없으면 데이터 베이스에서 조회한다.

 

1. em.find(Member.class, "member1")으로 해당 엔티티를 찾는다.

2. member1이 1차 캐시에 있으면 반환하고 없으면 DB에서 조회한다.

3. DB에서 조회한 테이터로 엔티티를 생성해서 1차캐시에 저장한다.(영속 상태)

4. 조회한 엔티티를 반환한다.

 

-> 1차 캐시는 메모리에 있으므로 성능상의 이점이 있다.

 

영속 엔티티의 동일성 보장

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

여기서 a == b는 참일까 거짓일까?

em.find(Member.class, "member1")를 반복해서 호출해도 영속성 컨텍스트는 1차 캐시에 있는 같은 엔티티 인스턴스를 반환한다. -> 따라서 영속성 컨텍스트는 성능상 이점과 엔티티의 동일성을 보장한다.

 

 

동일성과 동등성

- 동일성(identity) : 실제 인스턴스가 같다. 따라서 참조 값을 비교하는 == 비교의 값이 같다.

- 동등성(equality) : 실제 인스턴스는 다를 수 있지만, 인스턴스가 가지고 있는 값이 같다. 자바에서 동등성 비교는 equals() 메소드를 구현해야 한다.

 

3.4.2 엔티티 등록

엔티티 매니저는 트랜잭션을 커밋하기 전까지 데이터 베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소에 INSERT SQL을 차곡차곡 모아둔다. 그리고 트랜잭션을 커밋할 때, 모아둔 쿼리를 데이터베이스에 보내는데 이것을 트랜잭션을 지원하는 쓰기 지연이라 한다.

커밋시작 -> flush -> 커밋

 

3.4.3 엔티티 수정

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

//영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

//영속 엔티티 데이터 수정
member.setUsername("hi");
member.setAge(10);

//em.update(member) ????

tranaction.commit(); // 트랜잭션 커밋

 

변경감지

- JPA는 엔티티를 저장할 때, 최초의 상태를 복사해서 저장해두는데 이것을 스냅샷이라고 한다.

- 플러시 시점에 스냅샷과 엔티티를 비교해서 변경된 엔티티를 찾는다.

 

1. 트랜잭션을 커밋하면 엔티티 내부에서 먼저 플러시(flush())가 호출된다.

2. 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾는다.

3. 변경된 엔티티가 있으면 수정쿼리를 생성해서 쓰기 지연 SQL 저장소에 보낸다.

4. 쓰기 지연 저장소에 SQL 테이터베이스를 보낸다.

5. DB 트랜잭션을 커밋한다.

-> 변경감지는 영속성 컨텍스트가 관리하는 영속상태의 엔티티만 적용된다.

-> JPA의 기본전략은 엔티티의 모든필드를 업데이트한다.

 

JPA의 기본전략은 엔티티의 모든필드를 업데이트한다.

- 모든필드를 사용하면 수정쿼리가 항상 같다.(물론 바인딩되는 데이터는 다른다.)

따라서 애플리케이션 로딩 시점에 수정쿼리를 미리 생성해두고 재사용할 수 있다.

- 데이터베이스에서 동일한 쿼리를 보내면 데이터베이스는 이전에 한번 파싱된 쿼리를 재사용 할 수 있다.

- 필드가 많거나 저장되는 내용이 너무 크면 수정된 데이터만 사용해서 동적으로 UPDATE SQL을 생성하는 전략을 선택하면 된다. -> DynamicUpdate (DynamicInsert도 있다.)

 

3.4.4 엔티티 삭제

Member memberA = em.find(Member.class, "memberA");
em.remove(memberA);

em.remove()에 대상 엔티티를 넘겨주면 엔티티를 삭제한다.

물론 바로 삭제가 아닌 쓰기지연 방식으로 삭제하는데, 단 em.remove()가 호출되면 영속성 컨텍스트에서 제거된다.