Entity Manager Factory를 통해 고객의 요청이 올 때마다 Entity Manager를 생성합니다. 이 Entity Manager는 내부적으로 데이터베이스 커넥션을 사용해 DB를 사용합니다.
영속성 컨텍스트란 엔티티를 영구 저장하는 환경을 말합니다.
// 영속성 컨텍스트에 저장한다
EntityManager.persist(entity);Entity Manager를 생성하면 영속성 컨텍스트는 1:1 로 생성됩니다. (스프링 프레임워크 등은 N:1)
엔티티의 생명주기
- 비영속 (new/transient)
영속성 컨텍스트와 전혀 관계가 없는, 최초로 생성한 상태
// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");- 영속 (managed)
영속성 컨텍스트에 관리되는 상태
// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
// 객체를 생성한 상태(영속)
em.persist(member);영속 상태가 된다고 해서 DB에 바로 저장되지 않으며, Transaction을 commit하는 시점에서 DB에 저장됩니다.
persist해서 데이터를 넣을 때는 물론이고, em.find 등으로 조회를 했을 때 영속성 컨텍스트에 데이터가 없다면 영속성 컨텍스트로 가져와 영속상태가 됩니다.
- 준영속 (detached)
영속성 컨텍스트에 저장되었다가 분리된 상태. 영속성 컨텍스트가 제공하는 기능을 사용할 수 없습니다.
// 회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);em.detach(entity) // 특정 엔티티만 준영속 상태로 전환
em.clear() // 영속성 컨텍스트를 완전히 초기화
em.close() // 영속성 컨텍스트를 종료- 삭제 (removed)
삭제된 상태
// 객체를 삭제한 상태(삭제)
em.remove(member);영속성 컨텍스트의 이점
1차 캐시
// 엔티티를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
// 엔티티를 영속(1차 캐시에 저장됨)
em.persist(member);
// 1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");1차 캐시는 영속성 내부에 존재하며, 다음과 같은 구조로 나타낼 수 있습니다.
1차 캐시 구조
| (key) @Id | (value) Entity |
|---|---|
| "member1" | member |
JPA는 조회할때 DB보다 먼저 1차 캐시를 조회합니다.
DB에는 있지만 1차 캐시에는 없는 데이터의 경우,
1. find("member2") ➡️ 1차 캐시에 없음
2. DB 조회
3. 1차 캐시에 저장
4. member2를 재조회하면 1차 캐시에 있는 member2가 반환됨
JPA는 엔티티를 조회하면 무조건 영속성 컨텍스트에 올립니다.
1차 캐시를 영속성 컨텍스트로 이해해도 됩니다.
하지만 EntityManager는 보통 DB Transaction 단위로 생성되고, Transaction 단위가 끝날때 같이 종료되기 때문에 큰 장점은 아닙니다. (1차 캐시도 날라감)
동일성(identity) 보장
같은 Transaction 안에서 실행하면 동일성을 보장합니다.
Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
System.out.println(a == b); //동일성 비교 : true트랙잭션을 지원하는 쓰기 지연(transactional write-behind)
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
//엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야 한다.
transaction.begin(); // [트랜잭션] 시작
em.persist(memberA);
em.persist(memberB);
//여기까지 INSERT SQL을 DB에 보내지 않는다.
//커밋하는 순간 DB에 INSERT SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋영속성 컨텍스트 내부에는 쓰기 지연 SQL 저장소가 존재합니다. 데이터가 em.persist()를 통해 1차 캐시로 저장되는 동시에 JPA가 INSERT SQL을 생성해 쓰기 지연 SQL 저장소에 쌓아둡니다.
트랜잭션을 커밋하는 시점에 DB로 flush되면서 날라갑니다. 이 시점에서 실제 DB 트랜잭션에 커밋됩니다.
변경 감지(Dirty Checking)
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // [트랜잭션] 시작
// 영속 엔티티 조회
ember a = em.find(Member.class, "member1");
// 영속 엔티티 수정
member.setUsername("hi");
member.setAge(10);
transaction.commit(); // [트랜잭션] 커밋JPA는 DB Transaction을 commit하는 시점에 내부적으로 flush()가 호출됩니다. 그리고 엔티티와 스냅샷을 비교합니다. 여기서 스냅샷은 1차 캐시에 들어온 최초 시점의 상태를 말합니다.
| (key) @Id | (value) Entity | 스냅샷 |
|---|---|---|
| "memberA" | memberA | memberA 스냅샷 |
| "memberB" | memberB | memberB 스냅샷 |
스냅샷과 비교해 변경된 부분이 있다면 UPDATE SQL을 생성해 쓰기 지연 SQL 저장소에 쌓아둔 다음, 커밋하여 DB에 반영합니다.
🔻 플러시 (flush)
: 영속성 컨텍스트의 변경내용을 데이터베이스에 반영하는 것을 말합니다. 데이터베이스 트랜잭션이 커밋되면 플러시가 자동으로 발생합니다. (플러시가 발생한다고 데이터베이스 트랜잭션이 커밋되는 것은 아님)
- 변경 감지
- 수정된 에티티 쓰기 지연 SQL 저장소에 등록
- 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송 (등록, 수정, 삭제 쿼리)
영속성 컨텍스트를 플러시하는 방법
- em.flush() - 직접 호출
- 트랜잭션 커밋 - 플러시 자동 호출
- JPQL 쿼리 실행 - 플러시 자동 호출
플러시 모드 옵션
em.setFlushMode(FlushModeType.COMMIT)FlushModeType.AUTO: 커밋이나 쿼리를 실행할 때 플러시 (기본값) ✅FlushModeType.COMMIT: 커밋할 때만 플러시
- 영속성 컨텍스트를 비우지 않음
- 영속성 컨텍스트의 변경내용을 데이터베이스에 동기화
- 트랜잭션이라는 작업 단위가 중요 ➡️ 커밋 직전에만 동기화하면 됨
