JPA study 2주차 영속성 컨텍스트

entity manger는 db연결이 필요한 시점까지 커넥션을 얻지 않는다
트랜잭션을 시작할때 커넥션을 획득

 

여기서 말하는 커넥션이란 ?

그리고 그 커넥션들이 있는 커넥션풀이란 ?

 

웹 컨테이너(WAS)가 실행되면서 DB와 미리 connection(연결)을 해놓은 객체들을 pool에 저장해두었다가
클라이언트 요청이 오면 connection을 빌려주고, 처리가 끝나면 다시 connection을 반납받아 pool에 저장하는 방식을 말합니다.

트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된
엔티티를 데이터베이스에 반영 - flush

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

 

커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소에 SQL을 모아둠
그리고 커밋할때 모아둔 쿼리를 데이터베이스에 보낸다
이것을 쓰기 지연

변경감지

자동으로 반영하는 기능을 변경감지

JPA는 변경 감지(Drity Checking) 기능으로 엔티티를 변경할 수 있는 기능을 제공한다.

JPA는 엔티티를 영속성 컨텍스트에 보관할 때 최초 상태를 복사해서 저장해두는데 이것을 스냅샷이라 한다.
플러시 시점에 스냅샷과 엔티티를 비교해 변경된 엔티티를 찾는다

 

1차캐시

영속성 컨텍스트 내부에 캐시를 가지고 있다

DB 트랜잭션 안에서만 돌게 되는 것이다.

지연 로딩

내부 참조 객체를 실제 사용하는 시점에 조회하는 로딩 방법

내부 참조 객체의 사용을 잘 하지 않는 로직에 효율적(이론적)

1차캐시에 저장하면서 동시에 쓰기 지연 SQL저장소에 쌓아둔다.

 

flush와 commit의 차이

flush는 쿼리를 전송하는 역할, commit은 내부적으로 flush를 수행한 뒤 트랜잭션을 끝낸다.

따라서 flush로 전송된 쿼리틑 rollback할 수 있지만 commit은 트랜잭션이 끝나므로 rollback할 수 없다.

detach  분리
특정 준영속 상태로 만든다 ?
그렇기에 영속성 컨텍스트가 지원하는 어떤 기능도 동작X

clear - detach는 특정, clear는 전체

close - 영속성 컨텍스트를 종료하면 해당 영속성 컨텍스트가 관리하던게 준영속 상태가 된다.

준영속은 비영속에 가깝다.
하지만 식별값은 가지고 있다.

준영속에서 영속성 상태로 만드려면
merge를 해서 병합하면 된다.
새로운 영속상 상태의 엔티티를 반환

 

플러시 모드를 설정하지 않으면 자동으로 호출
영속성 컨텍스트에 보관된 엔티티를 지우는게 아닌 영속성 컨텍스트의 변갱 내용을 데이터 베이스에 동기화 하는것이 플러시

em.setFlushMode(FlushModeType.COMMIT)

커밋할 때만 플러시