EntityManager를 통해 생성되고 엔티티를 영속 상태로 관리(즉, EntityManager 인스턴스가 2개라면 영속성 컨텍스트도 2개가 존재하게 됨 - 1:1 관계)EntityManager는 JPA에서 엔티티를 관리하는 객체(주체)이고 영속성 컨텍스트는 엔티티를 관리하기 위한 저장소@Transactional 단위)EntityManager가 관리하는 엔티티 저장소이며 여기에 저장된 객체는 자동으로 변경 감지(Dirty Checking) 되고, 트랜잭션 종료 시점에 DB에 반영됨@PersistenceContext → EntityManager 주입
EntityManager가 아닌 프록시 객체 주입EntityManager를 찾아서 위임@Transactional 진입)
JpaTransactionManager)가 동작하면서 새로운 EntityManager 생성EntityManagerFactory.createEntityManager() 호출EntityManager가 스레드 로컬에서 현재 트랜잭션용 EntityManager를 찾아 사용EntityManager가 관리하는 영속성 컨택스트는 트랜잭션 내애서만 살아있음flush() 자동 호출 → DB 반영EntityManager.close() 호출
영속성 컨택스트 내부 캐시 및 스냅샷 완전 제거
단순 clear() 보다 강력한 소멸(객체 자체도 제거)
clear() VS close()
| 메서드 | 동작 | 시점 | 설명 |
|---|---|---|---|
clear() |
1차 캐시만 비움 (컨텍스트는 유지) | 트랜잭션 중간 | 대량 처리 시 메모리 정리용 |
close() |
컨텍스트 자체를 폐기 | 트랜잭션 종료 | 더 이상 영속성 관리 불가 |
영속성 컨텍스트 내부에 존재하는 Map(엔티티 ID, 엔티티 인스턴스) 형태의 저장소
따라서 같은 트랜잭션(영속성 컨택스트) 내에서 같은 엔티티 ID로 이미 조회한 엔티티는 DB를 다시 조회하지 않고 캐시(영속성 컨택스트)에서 반환됨(영속 상태 엔티티 한정)
1차 캐시가 중요한 이유
| 기능 | 설명 | 장점 |
|---|---|---|
| 조회 최적화 | 같은 엔티티를 반복 조회해도 한 번만 DB 조회 | 쿼리 부하 감소 |
| 동일성 보장 | 같은 PK의 엔티티는 항상 동일 객체 반환 | 애플리케이션 로직 안정성 향상 |
| 변경 감지 기반 | 트랜잭션 종료 전까지 객체 상태 추적 | update 쿼리를 최소화 |
key-snapshot 형태)UPDATE SQL을 생성하고 flush하여 DB에 반영