JPA 특징
- 1차 캐쉬 - 엔티티 조회
- 쓰기 지연 - 엔티티 등록
- 변경 감지 - 엔티티 수정
1차 캐쉬
- 영속성 컨텍스트 내부에 존재하는 캐쉬로 영속 상태의 엔티티는 모두 1차 캐쉬에 map의 형태로 저장
- key : @ID로 매핑한 식별자
- value : 엔티티
- 1차 캐쉬에서 조회
- Em.find()를 호출하면 우선 1차 캐쉬에서 식별자 값으로 엔티티를 조회
- 찾는 엔티티가 있으면 DB에서 조회하지 않고 메모리에 있는 1차 캐쉬에서 엔티티를 조회
- 찾는 엔티티가 1차 캐쉬에 없으면 엔티티 매니저는 DB의 조회 값으로 엔티티를 생성
- 생성된 엔티티는 영속성 컨텍스트에서 관리(=영속 상태)
- 성능상 이점과 엔티티의 동일성 보장
트랜잭션을 지원하는 쓰기 지연 (Transactional write-behind)
- 트랜잭션을 커밋할 떄 모아둔 쿼리를 테이터베이스로 전송
- 내부 쿼리 저장소에 커밋 직전까지 엔티티를 저장
- 트랜잭션을 커밋하면 엔티티 매니저는 영속성 컨텍스트를 flush(db와 동기화)
- 쓰기 지연 SQL 저장소에 모인 쿼리를 DB로 전송
- 연속성 컨텍스트의 변경 내용을 DB에 동기화한 후에 DB 트랜잭션을 커밋
- 쿼리 저장소에 쿼리가 많이 쌓이면, 동기화 시간과 커밋 시간이 증가할까(?)
SQL 수정 쿼리의 문제점
- 수정 쿼리가 많아 지는 것은 물론이고 비즈니스 로직을 분석하기 위해 SQL을 계속 확인
- 비즈니스 로직이 SQL에 의존하게 된다
변경 감지 (Dirty Checking)
- 엔티티의 변경 사항을 DB에 자동으로 반영
- JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태(snapshot)를 복사해서 저장
- flush 시점에 snapshot과 엔티티를 비교해서 변경된 엔티티를 검출
- 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용
- JPA의 기본적략은 엔티티의 모든 필드를 업데이트
- 단점 : 데이터 전송량이 증가
- 장점 : 수정 쿼리가 항상 동일하여 미리 준비 가능하며 재사용 가능
- @DynamicUpdate
- 컬럼이 많을 경우, 예를 들어 30개?, 변경된 값만 업데이트 가능하며 성능 향상 기대
- 모델링 실패 의심
Comments