JPA에서 가장 중요한 두가지
- ORM (객체과 관계형 데이터 베이스 매핑) Object Relational mapping
- 영속성 컨텍스트
엔티티 매니저 팩토리와 엔티티 매니저
- 사용자의 요청이 있을 때마다 엔티티 매니저 팩토리에서 엔티티 매니저를 각각 생성한다.
- 엔티티 매니저 팩토리는 어플리케이션 전체에서 딱 한번 생성하고 공유하여 사용함
- META-INF/persistence.xml에서 이름이 name인 영속성 유닛을 찾아 엔티티 매니저 팩토리를 생성함
영속성 컨텍스트
- 엔티티를 영구 저장하는 환경
- 영속성 컨텍스트는 논리적인 개념
- 눈에 보이지 않음
- 엔티티 매니저를 통해서 영속성 컨텍스트에 접근
엔티티의 생명주기
- 비영속 : 객체만 생성한 상태
Member m = new Member(150L, "ZZZ");- 영속 : 객체를 저장한 상태
Member m = new Member(150L, "ZZZ");
em.persist(m);- 준영속 : 객체를 영속성 컨텍스트에서 분리한 상태
/* flush 준영속 test
Member m = new Member(150L, "ZZZ");
em.persist(m);
em.flush();
Member member = em.find(Member.class, 150L);
member.setName("AAAAA");
em.detach(member);
*/- 삭제 : 객체를 삭제한 상태
em.remove(findMember);영속성 컨텍스트의 이점
- 1차캐시
- 1차 캐시에 저장하기 때문에 조회 시 DB까지 접근하지 않아도 값을 가져올 수 있어 미미하게 성능이 증가함(드라마틱하게 성능이 빨라지고 하진 않는다고함)
- 동일성(identity) 보장
- 1차 캐시로 반복 가능한 읽기(REPEATABLE READ) 등급의 트랜잭 션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공
- 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)
- 쓰기 지연 SQL 저장소에 쿼리를 모아뒀다가 커밋이 되는 시점에 대량으로 DB에 접근하여 작업함
- 변경 감지(Dirty Checking)
- 1차 캐시에 저장되는 시점의 스냅샷을 찍어두고 최종적으로 DB에 들어갈 때 변경된 값을 감지하고 비교하여 바뀐 값을 넣는다
- 지연 로딩(Lazy Loading)
flush
- 영속성 컨텍스트의 변경된 값을 데이터베이스에 반영
- 영속성 컨텍스트를 비우지 않음
- 영속성 컨텍스트의 변경내용을 데이터베이스에 동기화
- 트랜잭션이라는 작업 단위가 중요 -> 커밋 직전에만 동기화 하면 됨
flush 발생 시점 & 영속성 컨텍스트를 플러시하는 방법
- 변경 감지
- 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
- 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송(등록, 수정, 삭제 쿼리)
- em.flush() - 직접 호출
- 트랜잭션 커밋 - 플러시 자동 호출
- JPQL 쿼리 실행 - 플러시 자동 호출 -> 검색 쿼리 조회 시 영속 상태의 쿼리들을 DB에 넣어야만 검색이 가능해지므로
