영속성 컨택스트
엔티티 영구 저장하는 환경.
엔티티에 대한 캐시라고 생각.
애플리케이션과 db 사이 객체 보관하는 가상 db 같은 역할
엔티티 매니저 통해 엔티티 저장/조회 시 엔티티 매니저는 영속성 컨택스트에 엔티티를 보관/관리.
-
엔티티의 생명 주기
- 비영속(new, transient) : 영속성 컨텍스트와 전혀 관계가 없는 상태
- 영속(managed) : 영속성 컨텍스트에 저장된 상태
- 준영속(detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태
- 영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 더이상 관리하지 않으면 준영속 상태가 됨. 엔티티 준영속 상태 만들기 위해선 em.detatch(). 1차 캐시에서 빠진다고 생각하면 됨.
- 삭제(removed)
- 준영속 엔티티란?
https://velog.io/@wogud7587/JPA-준영속-상태와-변경-감지
영속성 엔티티가 더는 관리하지 않는 엔티티
DB에 한번 갔다온 엔티티
이미 DB에 한 번 저장되어서 식별자가 존재하는 엔티티는(기존 식별자를 가지고 있는 엔티티) 준영속 엔티티로 볼 수 있다
변경 감지(dirty checking) 일어나지 않음
영속성 컨텍스트의 특징 (https://velog.io/@neptunes032/JPA-영속성-컨텍스트란)
-
1차 캐시
영속성 컨텍스트 내부의 캐시. 영속 상태의 엔티티를 이곳에 저장.
데이터 조회 시 1차 캐시에 해당 데이터가 있는지 탐색한다. 없으면 데이터베이스에 접근해 값을 탐색한다. 탐색 결과를 바로 리턴하는 것이 아닌 다음 탐색에서 재사용 할 수 있도록 1차캐시에 저장한다. -
동일성 보장
엔티티의 동일성이 보장됨 -
쓰기 지연 (transactional write-behind)
바로 INSERT SQL이 DB에 보내지는 것이 아님.
엔티티 매니저는 트랜잭션 커밋 직전까지 내부 쿼리 저장소에 INSERT SQL 모아두고 트랜잭션 커밋 시 모아둔 쿼리 db에 보냄. -
변경 감지 (dirty checking)
ㄴ 영속성 컨텍스트에서 관리하는 엔티티에 대한 db상 실제 업데이트는 commit/flush 시 엔티티에 대한 값이 조회할 때를 기준으로 변경됐는지 확인 후, 한번에 db에 대한 업데이트. -
지연 로딩
엔티티가 실제로 사용되기 전까지 데이터베이스 조회를 지연할 수 있는 것.
즉 실제 사용하는 시점에 데이터베이스에서 필요한 데이터를 가져오는 것.
하지만 실제 엔티티 객체 대신 가짜 객체가 필요한데 이것이 프록시 객체 이다.
-
프록시 객체
https://girawhale.tistory.com/129
지연로딩 사용시 (EntityManager.getReference()) db 접근 위임한 프록시 객체 반환.
실제 클래스를 상속받아 만들어지므로 실제 클래스와 모양이 동일하므로 사용자는 구분 없이 그대로 사용하면 됨.
실 객체에 대한 참조(target)을 보관.
프록시 객체에 메소드를 호출했을 때 실제 엔티티가 없다면 영속성 컨텍스트에 실제 엔티티 생성을 요청하고 영속성 컨텍스트는 데이터베이스를 조회해 실제 엔티티 객체를 생성한다. 실제 엔티티에 대한 참조로 실제 엔티티의 메소드를 호출해 결과를 반환한다. -
플러시
영속성 컨텍스트의 변경 내용 db에 반영.
영속성 컨텍스트의 엔티티를 지우는게 아니라 변경 내용을 데이터베이스에 동기화하는 것. -
플러시의 흐름
- 변경 감지가 동작해서 스냅샷과 비교해서 수정된 엔티티를 찾는다.
- 수정된 엔티티에 대해서 수정 쿼리를 만들고 SQL 저장소에 등록한다.
- 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.
