참고자료
엔티티(Entity) 객체
- 디비 레코드와 대응하는 객체
- 예)
order
테이블에서pk = 1
에 해당하는 레코드 ↔︎Order(pk=1)
엔티티 객체
영속 객체 (Persistence Object)
- 영속성 컨텍스트의 관리 대상이 되는 객체.
영속성 컨텍스트 (persistence context)
- 엔티티 ~ 디비 레코드 간의 괴리를 줄여준다.
- 엔티티 객체의 생명주기를 관리한다.
- 비영속 (new) : 영속성 컨텍스트에 아직 없음
- 영속 (managed) : 영속성 컨텍스트에 엔티티 객체가 관리됨
- 준영속 (detached) : 영속성 컨텍스트에 있지만 관리 대상이 아님 (주로 DB 세션이 끝나면 영속 → 준영속으로 전환)
- 삭제 (removed) : delete 쿼리에 의해 영속성 컨텍스트에서 삭제
- 엔티티 매니저가 영속성 컨텍스트를 주입받는다.
- [서비스 → 리퍼지토리 → 엔티티매니저 → 영속성 컨텍스트 → 디비] 레이어로 나뉨
영속성 컨텍스트는 아래 2가지로 나뉜다.
transaction-scoped 영속성 컨텍스트
- 트랜잭션 단위로 유지되는 영속성 컨텍스트
transaction-scoped 영속성 컨텍스트의 역할
- 트랜잭션 단위로 앤티티 객체 캐싱 (aka. first-level cache)
- 리퍼지토리 레이어에서 레코드 조회 → 영속성 컨텍스트에 엔티티 객체가 이미 있으면 DB 에 select 쿼리 수행하지 않고 영속성 컨텍스트에 있는 엔티티 객체 반환
- flush insert/delete/update queries in transaction
- DB 에 연결하기 전에 트랜잭션 맥락 내에 작성된 insert/delete/update 쿼리들을 모아놨다가 한꺼번에 flush (트랜잭션 맥락 중간에 예외가 발생하면 DB 연결없이 애플리케이션 단에서 롤백이 가능해서 DB I/O 비용을 줄인다)
- transaction-scoped 영속성 컨텍스트를 주입받은 엔티티 매니저를 통해 트랜잭션 없이 insert/delete/update 시도할 경우
TransactionRequiredException
예외 발생
- 엔티티 객체의 필드 변경 감지 (dirty check)
- 직접
save()
하지 않더라도 알아서 update 쿼리 수행
extended-scoped 영속성 컨텍스트
- cross-transaction 단위로 (애플리케이션 서버가 뜬 이후 ~ 죽기 전 까지) 유지되는 컨텍스트
extended-scoped 영속성 컨텍스트의 역할
- cross-transaction 단위로 엔티티 객체 캐싱 (aka. second-level cache)
- 1차 캐시와 비슷하지만 트랜잭션 단위로 컨텍스트가 isolation 되는 게 아니고 애플리케이션 내에 모든 컴포넌트에서 동일한 엔티티 객체에 접근 (모든 엔티티매니저가 동일한 영속성 컨텍스트를 공유)
- 애플리케이션 전체에서
select
빈도가 높고update
빈도는 낮은 엔티티 객체에 적절
- extended-scoped 영속성 컨텍스트를 주입받은 엔티티 매니저를 통해 동일한 엔티티 객체(유니크 키가 동일한 객체?)를 중복으로
insert
하려고 하면EntityExistsException
예외 발생