[JPA] 영속성 컨텍스트 라이프사이클

https://hehesim.tistory.com/59

JPA (Java Persistence API) 기초/설정

이어서....

 

Persistence Context (PC)의 라이프 사이클을 배워봅시다...

 

1. Create

- EntityManager가 생성되면 영속성 컨텍스트가 생성된다. >> EntityManager manager = factory.createEntityManager();

2. Transient state

- Book book = new Book("JPA", "무명"); >> book 객체 생성. 

생성하면 ~~~> 지금은 PC와는 연관이 없다.

3. Managed state

- manager.persist(book);  >> 매니저가 persist를 한 순간 PC에 JPA Entity instance가 생긴다.

---

** 여기서 SELECT / DELETE / UPDATE가 가능!!!! 

1) SELECT : Entity 조회 >> manager.find(Book.class, book1.getId());

~> 조회 요청 시, 먼저 PC에서 해당 엔티티 존재하는지 찾고, 없으면 DB에서 조회 후 조회된 엔티티를 PC에 가지고옴. 

PC에 존재하면 굳이 DB에 접근하지 않고 기존 엔티티 반환.

 

2) DELETE : Entity 제거 >> manager.remove(book); 

~> remove() 요청시, 먼저 PC에서 해당 엔티티 제거. (DB에서는 아직 제거되지 않음!!!) 

~> tx.commit() 수행 시, flush() 호출 되면서 DELETE 쿼리가 수행되어 DB에서 제거됨. 

3) UPDATE : Entity 갱신 >> JPA에는 별도 API가 없다. > 변경하고자 하는 엔티티의 값을 자바 코드에서 변경 후 persist(entity)를 통해 다시 영속화를 수행하면 > PC는 자동으로 변경을 감지한다. (**Automatic Dirty Checking)

~> Book book = manager.find(Book.class, 1);   // 처음 영속화된 엔티티 복사본.

~ >book.updateBookName("abc");    //자바 코드 메소드 (업데이트)

~> manager.persist(book);    // 업데이트된 엔티티 복사본 (flush이전임.) > 자동으로 dirty checking 엔티티 두개를 비교한다.

~> tx.commit();   // 이때 flush() 호출되면서 비교결과가 다르므로 update 쿼리가 실행됨. 

---

4. EntityTransaction commit() called

- tx.commit();   >>  내부적으로 flush() 호출. 

** flush() : 영속성 컨텍스트의 캐시에 보관되어 있는 엔티티 참조 정보와 DB내의 레코드를 비교한 다음 >> 동기화 진행함.

5.  Detached state 

: Entity 준영속화, 비영속화.

- 엔티티를 PC에서 관리되지 않도록 적용되는 라이프사이클.

- manager.detach(entity); >> PC에 있던 엔티티와 연결성이 끊김! >> 이 경우 entity가 PC에 존재하는지 확인해보면 없다!! 

(정확하게 말하면 manager > 에서 detached 상태가 되는 시점은 session이 close()되는 시점이라고 한다... manager.close(); 가 호출되었을 때래요)

 

6. 영속성 컨텍스트 제거

- manager.close(); >> 엔티티매니저 닫기. > 이 때 해당 매니저에게 매핑되었던 영속성 컨텍스트도 사라짐.

 

PC 영속성 컨텍스트의 인생은 

1. 태어남 create

2. 아기시절 아직 직접적 연관은 없다... transient state

3. 어른시절 본격적으로 인생에 발을 들였다..하고싶은거 다해... managed state >> 이 때 select, update, delete 가능... 본격적 활동 시작ㅋ 예를 들어 매일 엽떡먹기.

4. commit(); & flush(); >> 이걸 하면 내 인생이 바뀔거 같다는 그 불안한 느낌이 있는...사건들 ㅋ ㅋ ㅋ 예를 들어 엽떡 먹다가 위에 구멍 뚫릴거 같은데 그래도 먹음. 그 결과 진짜 위에 구멍 뚫림..ㅋ 

5. 인생 후회 .... manager.detach() 엔티티 준영속화 >> 갑자기 몸 챙겨서 위가 나아짐

6. die... 영속성 컨텍스트 제거 >> 죽음ㅋ

 

이렇게 라이프사이클 끝~~~~

 

 

WHY ? 영속성 컨텍스트 왜 있지???

1. 1차 캐시

1차 캐시에 엔티티 자체가 저장되면서 

같은 트랜잭션 내에서 find() 할 경우 엔티티가 있는지 확인하고 PC에 있으면 굳이 DB까지 가지 않는다~

 

2. 동일성 보장.

PC에 저장된 엔티티를 두번 조회해도 같은 레퍼런스가 된다.

 

3. 쓰기 지연

엔티티들을 PC에 저장되어 있고, 관련한 여러 쿼리들을 수행하는 코드를 짜서 persist() 하면 ?

바로 DB로 쿼리문을 보내는 것 아니라~

여러가지 쿼리들을 생성해서 쌓아놓다가 flush()/commit() 하는 시점에 DB에 동시에 쿼리들을 보낸다.