JPA PersistContext
이 문서는 Hibernate ORM 공식문서를 읽으며 정리한 글입니다.
Hibernate.Session 과 EntityManager 의 API 는 데이터를 지속성있게 다룰 수 있도록 해주는데 이를 Persistence Context 라 한다.
Persistence Context 에서 관리되는 데이터는 기본적으로 database 와 persistence context 양쪽에서 연관된 상태로 관리된다.
Persistence data 는 아래와 같은 생명주기를 가진다.
LifeCycle
비영속 (transient) : 엔티티가 만들어졌지만 아직까지 Persistence Context 와 연관이 없는 상태를 뜻합니다.
위와 같이 Memer Entity 는 초기화가 됬지만, 아직 영속성 컨텍스트에 관리되지 않고있음을 의미합니다.
영속(managed / persistent) : 엔티티가 Persistence Context 와 연관된 상태를 뜻하며 Identifier 로 식별 가능한 상태를 뜻합니다. 데이터 베이스에 있거나 혹은 아직은 없을 수도 있습니다.
위와 같이 EntityManager 에 Persist 되는 순간 Persistence Context 에 관리됩니다.
비영속(detached) : Persistence Context 에서 관리되다가 분리된 것을 뜻합니다.
위와 같이 detach 됬을때는 dirtyChecking 이 안되는 것을 볼 수 있습니다.
즉, 영속성 컨텍스트에 의해 관리가 되지 않기 때문입니다.
아래 관리되고 있을때 예시를 한번 보시죠.
여기서는 정상적으로 update query 가 발생하는 것을 알 수 있습니다.
삭제 (removed) : 삭제 상태는 Persistence Context 에 식별자로 관리되고 있다가 삭제된 객체를 뜻합니다. 데이터 베이스에서 또한 삭제 됩니다.
Dirty Checking
Dirty Checking 은 Hibernate 에서 Persistence Context 에 의해 관리되는 Entity 가 변경됬는지 여부를 계산하는 것을 의미한다.
어떻게 Hibernate 는 이걸 알 수 있을까?
그건 바로 Hibernate 는 데이터베이스에서의 엔티티 상태에 대한 마지막 이력을 관리하고 있기 때문이다.
Persistence Context 를 플러시하는 과정에서 하이버 네이트는 관리되는 모든 엔티티에 대하여
"last known database state" 와 다른점이 없는지를 점검한다.
그래서 PC 에 의해 관리되는 많은 수의 엔티티가 있다면, 성능이 저하될 수도 있다. (처음 알았네..)
만약 DataType 의 내부 상태 변경에 신경쓰지 않는다면, Bytecode-EnhanceMent 로 Dirty Checking 를 강화할 수 있다고 한다.
Class 의 바이트 코드를 조작해서 엔티티에 직접 Dirty Checking 을 추적할 수 있다고 한다.
그래서 Flush 시간에 Hibernate 는 diff 를 계산할 필요없이 Entity 에세 변경점을 묻게 된다.
흠 Spring Data JPA 는 어떤걸 쓰고 있을꺄? 전자인가..?
일단 컴파일된 Entity 파일에 변경점을 질문할 수 있는 코드가 없는걸 봐서 전자일 거 같다는 생각이 든다.
아, 알아보니 이런 설정을 따로 해줘야 된다고 한다.
CascadeType
여기서는 기본적으로 CascadeType.ALL 에 대해서만 언급하려고 한다.
나머지가 궁금하면 미안한데 찾아보길 바란다 ㅠㅠ.. 글이 너무 길어질까봐 궁금한점만 정리하려고 한다.
일단 Entity 가 DB 에 올라가기 위해서는 PC 에 의해 관리되야 한다는 점을 깨달았을 것이다.
만약 아래처럼 1:N 관계가 있다고 해보자.
내가 원하는건 Team 의 List 에 Member 를 추가했을때 같이 DB 에 저장되게 하고 싶다.
그렇다면 Team 이 영속화될때 Member 또한 영속화 시켜야 할 것이다.
따라서 아래와 같은 옵션을 줘보자
아래와 같이 테스트를 해보면 잘 통과하는 모습을 확인할 수 있다.
그런데 궁금한 점이 하나 생겼다.
만약에 Team 안의 멤버를 변경해도 변경점을 찾을 수 있을까? 테스트를 해보자.
DB 에 이렇게 있다고 해보자.
결과가 어떨까?
실패하는 모습을 볼 수 있다. 왜일까?
CascadeType.REPLICATE 옵션이 없기 때문이다. 하지만 이것은 공개 옵션으로 따로 나와있지는 않다.
보면 알수 있듯이 ALL 을 쓰면 이를 사용할 수 있다.
그렇다면 옵션을 한번 바꿔보자.
UPDATE Query 가 나가면서 TEST 가 통과했다.
