JPA + 영속성 관리

JPA

1. 1차 캐시와 동일성 보장

- 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상

- DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeattable Read 보장

 

2. 트랜잭션을 지원하는 쓰기 지연 - INSERT

- 트랜잭션을 커밋할 때까지 INSERT SQL을 모음.

- JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송.

 

3. 지연 로딩과 즉시 로딩

- 지연 로딩 : 객체가 실제 사용될 때 로딩

- 즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회

 

ORM은 객체와 RDB 두 기둥 위에 있는 기술

 

주의

- 엔티티 매니저 팩토리는 하나만 생성해서 애플리케이션 전체에서 공유

- 엔티티 매니저는 쓰레드간에 공유X (사용하고 버려야 한다);

- JPA의 모든 데이터 변경은 트랜잭션 안에서 실행

 

JPQL 소개

-가장 단순한 조회 방법

> EntityManger.find()

> 객체 그래프 탐색 (a.getB().getC())

- 나이가 18살 이상인 회원을 모두 검색하고 싶다면??

 

JPA에서 가장 중요한 2가지

- 객체와 관계형 데이터베이스 매핑하기

- 영속성 컨텍스트

 

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

 

EntityManagerFactory

>고객 요청시 EntityManager를 생성해준다.

 

영속성 컨텍스트란 ?? >>> '엔티티를 영구 저장하는 환경'

 

엔티티의 생명주기

 

- 비영속 (new/transient)

> 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 (객체만 생성한 상태)

 

- 영속 (managed)

> 영속성 컨텍스트에 관리되는 상태 (객체를 저장한 상태 -> em.p)

 

- 준영속 (detached)

> 영속성 컨텍스트에 저장되었다가 분리되는 상태

 

- 삭제 (removed)

> 삭제된 상태

 

 

엔티티 조회, 1차 캐시

> 엔티티 조회 시, 영속 컨텍스트 내의 1차 캐시에서 조회

멤버 엔티티에서 캐시의 값이 있을 경우 1차 캐시에서 값을 반환한다.

 

- 데이터베이스에서 조회

1. 1차 캐시에 없을 경우 

2. DB 조회

3. 1차 캐시에 저장

4. 반환

 

>>>> 사실 큰 도움은 안된다.. 엔티티 매니저는 대단위에서 트랜잭션을 만들고 지워버린다.

여러명의 고객이 사용하는 캐시가 아닌 한 트랜잭션 안에서만 효과가 있다. 성능 이점 X

 

JPA 변경 감지

1.flush()

2. 엔티티와 스냅샷 비교 (1차 캐시)

3. UPDATE SQL 생성 (쓰기 지연 SQL 저장소) em.persist() 사용 x

4. flush

5. commit

 

플러시(flush)