[TIL 2022-2-11] JPA 영속성 콘텍스트(Persistence Context)

영속성 콘텍스트

- 엔티티를 영구 저장하는 환경.

왜 영구라는 단어를 쓰는지는 아직 안와닫는 것 같다. 지금 생각은 하나의 트랜잭션이 끝날 때까지 조회, 수정, 생성된 엔티티 객체를 관리하는 공간 정도로 이해된다. (아니면 엔티티를 영구 저장하는(역할을 관리하는) 환경은 아닐까 추측해본다)

 

- persist() 메소드는 엔티티객체를 영속화(영속성 컨텍스트에 저장)하는 역할

 

- 엔티티 매니저가 생성되면 그안에 영속성 콘텍스트와 1:1로 생성(스프링에선 다르게 동작)

스프링에서 @Transactional 를 통해 트랜잭션을 관리하는데 이렇게 설정된 메소드안에서는 엔티티 매니저가 서로 다르더라도 같은영속성 컨텍스트를 공유한다.(엔티티 메니저 객체:영속성 컨텍스트 가 1:1 이 아니라 N:1)

https://www.inflearn.com/course/ORM-JPA-Basic/lecture/21690?tab=community&volume=1.00&speed=1&q=318025 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 학습 페이지

 

- 비영속, 영속, 준영속

비영속 - 엔티틱 객체가 하나의 트랜잭션 안에서 영속성 콘텍스트에 한번도 추가되지않는상태 

영속 - 엔티티 객체가 영속성 콘텍스트에 추가되어 관리되는 상태

준영속 - deTatch() 메소드를 통해 콘텍스트에서 제거(DB X). 비영속 상태와 거의 같지만 엔티티 객체가 기본키로 맵핑되는 ID를 가지고 있음

 

- 영속성 컨텍스트에 이점

동일성 보장 - 같은 트랙잭션 내에서 영속성 콘텍스트에 존재하는 엔티티 객체 조회시, 조회 횟수에 상관없이 모두 동일(ArrayList의 get() 메소드처럼)

 

- 트랜잭션을 통한 쓰기 지연

한 트랜잭션 내에서는 persist()를 통해 영속화 돼도 commit()이 호출되기 전까지 디비에 SQL을 보내지 않음. 영속화될 때 생성된 SQL은 쓰기 지연 SQL 저장소에 저장되고 커밋되면서 한번의 네트워크의 모든SQL이 실행됨

 

- 변경 감지(Dirty checking) - 스냅샷

영속성 컨택스트 내의 1차캐시에는 엔티티객체의 키와, 객체, 그리고 처음 엔티티가 영속화될때 생성된 스냅샷이 함께 저장된다. 이는 영속화된 시점의 엔티티의 복사본으로 flush 가 일어나면 엔티티와 스냅샷을 비교하고, 변경이있으면 UPDATE쿼리를 생성해 쓰기 지연 SQL 저장소에 올리고, SQL UPDATE 쿼리 생성이 끝나면 디비에 쿼리를 보낸다.

 

플러시 - 영속성 컨텍스트에 변경사항을 디비에 반영,  flush() 메소드 호출, 트랜잭션이 커밋될 때, JPQL 쿼리 실행시 발생

 

- 쓰기 지연

 

 

객체와 테이블 매핑

- @Entity

JPA가 관리하는 클래스를 지정. 테이블과 매핑할 클래스는 필수로 기입해야한다. 엔티티 클래스는 기본생성자가 필수

 

- 데이터베이스 스키마 자동 생성 hibernate.hbm2ddl.auto

perseistence.xml의 정의하여 사용할 수 있음. 아래와 같은 옵션을 사용create: 기존 테이블 삭제 후 다시 생성create-drop: create 옵션 + 종료시 모든 테이블 dropupdate: 변경분만 반영

 

---

참고

https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의