[JPA] 3.영속성 관리 - 내부 동작 방식

[JPA] 3.영속성 관리 - 내부 동작 방식

 

1. 영속성 컨텍스트 

JPA에서 가장 중요한 두 가지

1) 객체와 관계형 데이터베이스 맵핑 (Object Relational Mapping)

2) 영속성 컨텍스트

 

엔티티 매니저 팩토리와 엔티티 매니저

- 고객의 요청이 올 때마다 EntityManagerFactory가 EntityManage 생성 -> EntityManager가 내부적으로 DB Connection 사용해서 DB 사용

 

영속성 컨텍스트

- JPA를 이해하는데 가장 중요한 용어

- 엔티티를 영구 저장하는 환경이라는 뜻

- EntityManager.persist(entity);

 

- 영속성 컨텍스트는 논리적인 개념

- 눈에 보이지 않음

- EntityManager를 통해서 영속성 컨텍스트에 접근

 

- EntityManager 생성하면 1대1로 영속성 컨텍스트 생성 (PersistenceContext)

- EntityManager 안에 PersistenceContext라는 공간이 생김

 

 

- 스프링 프레임워크의 경우 다대일

 

엔티티의 생명주기

- 비영속 (new/transient)  :  영속성 컨텍스트와 전혀 관계가 없는 새로운 상태

- 영속 (managed)             :  영속성 컨텍스트에 관리되는 상태

- 준영속 (detached)          :  영속성 컨텍스트에 저장되었다가 분리된 상태

- 삭제 (removed)              :  삭제된 상태

 

(a) 비영속 (new/transient)

// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

- 맴버객체 생성했는데 entityManager에 아무것도 안넣고 객체만 생성한 상태

- JPA와 관련 X

 

(b) 영속 (managed)

// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

// 객체를 저장한 상태(영속)
em.persist(member);

* 영속상태라고 db에 쿼리가 날라가는 것이 아님

* transaction commit하는 시점(tx.commit())에 영속성 context에 있는 애가 db 쿼리가 날라가게됨

 

(c) 준영속 (detached), (d)삭제

// 회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);

// 객체를 삭제한 상태(삭졔)
em.remove(member);

 

영속성 컨텍스트의 이점

- 1차 캐시

- 동일성(identity) 보장

- 트랜잭션을 지원하는 쓰기 지연 (transactional wirte-behind)

- 변경 감지 (dirty checking)

- 지연 로딩 (lazy loading)

 

(a) 엔티티 조회, 1차 캐시

// 엔티티를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

// 엔티티를 영속
em.persist(member);

- 영속성 컨텍스트 내부에 1차캐시 들고있음 (1차캐시=영속성 컨텍스트 라고 해도 무방)

- em.persist(member) 통해서 1차 캐시에 저장

- key(@id), value(Entity) = ("member1", member객체)

 

 

1차 캐시에서 조회

Member findMember = em.find(Member.class, "member1");

- db를 뒤지는 것이 아니라 1차캐시에서 조회해옴

- 만약 member2를 조회하면 (emf 다시 생성해서 1차캐시에 없음) -> 1차캐시에 저장후 -> member2 반환

 

(b) 동일성 보장

member a = em.find(Member.class, "member1");
member b = em.find(Member.class, "member1");

System.out.println(a == b); // 동일성 비교 true

- 1차 캐시로 반복 가능한 읽기(Repeatable Read) 등급의 트랜잭션 격리 수준을 DB가 아닌 애플리케이션 차원에서 제공

 

(c) 엔티티 등록 - 트랜잭션을 지원하는 쓰기 지연

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

// 엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야함
transaction.begin();

em.persist(memberA);
em.persist(memebrB);
// 여기까지는 INSERT SQL를 DB에 보내지 않음

// 커밋하는 순간 DB에 INSERT SQL 보냄
transaction.commit();

> em.persist(memberA)

- memberA 1차 캐시에 저장

- JPA가 엔티티 분석해서 INSERT SQL 생성 

- 쓰기 지연 SQL 저장소에 SQL을 쌓아둠

 

 

> em.persist(memberB)

- memberB 1차 캐시에 저장

- SQL INSERT SQL 생성해서 쓰기 지연 SQL 저장소에 쌓아둠

 

>transaction.commit();

 

- 쌓인 SQL을 DB에 한번에 보낼수있음 (JDBC 배치 개념)

옵션에서 조절 가능 -> hibernate.jdbc.batch_size / value

(버퍼링 기능)

 

* JPA는 객체(Entity)에 생성자 만들 때 기본 생성자 public Member() {} 하나 있어야함

 

(d) 변경 감지 (Dirty Checking)

- 엔티티 조회후 값 변경하면 자동으로 UPDATE

- 트랜잭션 커밋 -> flush -> 엔티티랑 스냅샷 비교 -> update쿼리 쓰기지연저장소 넣고 -> flush -> commit

 

엔티티 삭제

// 삭제 대상 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

// 엔티티 삭제
em.remove(memberA);

 

(e) 지연 로딩

??

---

2. 플러시

플러시

- 영속성 컨텍스트의 변경내용을 데이터베이스에 반영

 

플러시 발생

- 변경 감지

- 수정된 엔티티 쓰기 지연 SQL 저장소에 등록

- 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송 (등록 / 수정 / 삭제 / 쿼리)

 

영속성 컨텍스트를 플러시하는 방법

- em.flush() : 직접 호출

- 트랜잭션 커밋 : 플러시 자동 호출

- JPQL 쿼리 실행 : 플러시 자동 호출 (em.persist로 memberA,B,C 넣었는데 flush 안하면 DB에서 조회가 안됨)

 

플러시 모드 옵션

em.setFlushMode(FlushModeType.COMMIT)

- FlushModeType.AUTO      :  커밋이나 쿼리를 실행할 때 플러시 (기본값)

- FlushModeType.COMMIT :  커밋할 때만 플러시

 

플러시는!
- 영속성 컨텍스트를 비우지 않음

- 영속성 컨텍스트의 변경내용을 데이터베이스에 동기화

- 트랜잭션이라는 작업 단위가 중요 -> 커밋 직전에만 동기화하면 됨

 

---

3. 준영속 상태

- 영속 -> 준영속

- 영속 상태의 엔티티가 영속성 컨텍스트에서 분리 (detachd)

- 영속성 컨텍스트가 제공하는 기능을 사용 못함

 

준영속 상태로 만드는 방법

- em.detach(entity) : 특정 엔티티만 준영속 상태로 전환

- em.clear()              : 영속성 컨텍스트를 완전히 초기화

- em.close()              : 영속성 컨텍스트를 종료