3.4 영속성 컨텍스트의 특징
- 영속성 컨텍스트와 식별자 값
- 엔티티를 식별자 값(@id로 테이블의 기본 키와 매핑한 값)으로 구분
- 영속 상태는 식별자 값이 반드시 있어야 한다.
- 식별자 값이 없으면 예외 발생.
- 영속성 컨텍스트와 데이터베이스 저장
- JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영
- 플러시(flush)
- 영속성 컨텍스트가 엔티티를 관리하는 것의 장점
- 1차 캐시
- 동일성 보장
- 트랜잭션을 지원하는 쓰기 지연
- 변경 감지
- 지연 로딩
3.4.1 엔티티 조회
- 영속성 컨텍스트는 내부에 캐시를 가지고 있음 => 1차 캐시
- 영속 상태의 엔티티는 모두 이곳에 저장
영속성 컨텍스트 내부에 Map이 하나 있음
키는 @Id로 매핑한 식별자이고 값은 엔티티 인스턴스
// 엔티티를 생성한 상태(비영속)
Member member = new Member();
member.setId(100L);
member.setUsername("회원1");
// 엔티티 영속
em.persist(member);
- 1차 캐시의 키는 식별자 값
- 식별자 값은 데이타베이스 기본 키와 매핑
- 영속성 컨텍스트에 데이터를 저장하고 조회하는 모든 기준은 데이타베이스 기본 키 값.
엔티티 조회
Member member = em.find(Member.class, 100L);
중요한 부분
em.find() 호출 => 1차 캐시에서 엔티티 조회
엔티티가 1차 캐시에 없으면 데이터베이스 조회
1차 캐시에서 조회
- em.find() 호출
- 우선 1차 캐시에서 식별자 값으로 엔티티 찾음.
- 찾는 엔티티가 있으면 데이타베이스 조회하지 않고, 메모리에 있는 1차 캐시에서 엔티티를 조회
1차 캐시에 있는 엔티티 조회
Member member = new Member();
member.setId(100L);
member.setUsername("회원1");
// 1차 캐시에 저장됨
em.persist(member);
// 1차 캐시에서 조회
Member findMember = em.find(Member.class, 100L);
데이터베이스에서 조회
- 엔티티가 1차 캐시에 없으면 엔티티 매니저는 데이터베이스를 조회해서 엔티티를 생성.
- 1차 캐시에 저장한 후에 영속 상태의 엔티티를 반환.
분석
- em.find(Member.class, 200L)를 실행.
- member2가 1차 캐시에 없으므로 데이터베이스에서 조회.
- 조회한 데이터로 member2 엔티티를 생성해서 1차 캐시에 저장한다.(영속상태)
- 조회한 엔티티를 반환
영속 엔티티의 동일성 보장
Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
System.out.println(a == b); // 동일성 비교
- 결과는 "참"
- 둘은 같은 인스턴스
- 영속성 컨텍스트는 성능상 이점과 엔티티의 동일성을 보장한다.
3.4.2 엔티티 등록
엔티티 등록 코드
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
// 엔티티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다.
transaction.begin(); // 트랜잭션 시작
em.persist(memberA);
em.persist(memberB);
// 여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.
// 커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); // 트랜잭션 커밋
- 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스의 엔티티를 저장하지 않음.
- 내부 쿼리 저장소에 INSERT SQL을 차곡차곡 모아둔다.
- 트랜잭션 커밋할 때 모아둔 쿼리를 데이터베이스에 보낸다.
- 트랜잭션을 지원하는 쓰기 지연
쓰기 지연, 회원 A 영속
쓰기 지연, 회원 B영속
트랜잭션 커밋, 플러시, 동기화
- 트랜잭션 커밋.
- 엔티티 매니저 -> 영속성 컨텍스트 플러시.
- 데이타베이스 동기화 -> 등록, 수정, 삭제한 엔티티를 DB에 반영.
- 쓰기 지연 SQL 저장소에 모인 쿼리를 데이터베이스에 보낸다.
- 마지막으로 실제 데이타베이스 트랜잭션 커밋.
트랜잭션 범위 안에서 실행.
등록 쿼리를 그때 그때 데이타베이스에 전달해도 트랜잭션을 커밋하지 않으면 아무 소용이 없음.
3.4.3 엔티티 수정
- JPA는 엔티티를
수정할 때는 단순히 엔티티를 조회해서 데이터만 변경하면 된다. - update()라는 메소드 없음.
- 변경 감지 기능을 사용해서 데이타베이스에 자동 반영
플러시 시점에 스냅샷과 엔티티를 비교
수정 순서
- 트랜잭션 커밋 -> 엔티티 매니저 내부에서 먼저 플러시 호출
- 엔티티와 스냅샷을 비교해서 변경된 엔티티 찾는다.
- 변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소로 보낸다.
- 쓰기 지연 저장소의 SQL을 데이터베이스로 보낸다.
- 데이터베이스 트랜잭션을 커밋
변경감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용된다.
업데이트 기본 전략
JPA의 기본전략은 모든 필드를 업데이트한다.
- 모든 필드를 사용하면 수정 쿼리가 항상 같음.
- 동일한 쿼리를 보내면 데이터베이스는 이전에 파싱된 쿼리는 재사용.
필드가 많거나 저장되는 내용이 큰 경우
하이버네이트 확장 기능 사용
@Entity
@org.hibernate.annotation.DynamicUpdate
@Table(name = "Member")
public class Member {...}
수정된 데이터만 사용해서 동적으로 UPDATE SQL을 생성
3.4.4 엔티티 삭제
엔티티를 삭제하려면 먼저 삭제 대상 엔티티를 조회해야 한다.
Member memberA = em.find(Member.class, 100L); // 삭제 대상 엔티티 조회
em.remove(memberA); // 엔티티 삭제
- 엔티티를 즉시 삭제하는 것이 아님
- 삭제 쿼리를 쓰기 지연 SQL 저장소에 등록
- em.remove(memberA)를 호출하는 순간 영속성 컨텍스트에서 제거