이미 몇번씩 들었던 영속성 관리 강의를 정리하려고 한다. JPA 를 사용하면서 가장 인상 깊게 들었고 꽤 정리 할 부분이 많아 보였기에 기록을 남긴다.
영속성 컨텍스트
영속성 컨텍스트
영속성 컨틱스트란?
- "엔티티를 영구 저장하는 환경" 을 뜻한다
- 논리적인 개념이고 엔티티 매니저를 통해서 접근해야한다.
강의 1회차에서는 이해를 못했지만 스프링 프레임워크 기본을 키우고 보니 이해가 간다. 엔티티 매니저를 한번 생성하면 1:1로 영속성 컨텍스트가 생성이 된다. 그리고 여러개의 엔티티 매니저는 결국 같은 영속성 컨텍스트를 가리키고 있다. 마치 스프링 프레임워크가 싱글톤으로 유지하듯이 N:1이다.
엔티티의 생명주기
엔티티의 생명주기로는 크게 4가지 단계가 나뉜다.
- 비영속:
영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 - 영속:
영속성 컨텍스트에 관리되는 상태 - 준영속:
영속성 컨텍스트에 저장되었다가 분리된 상태 - 삭제:
삭제된 상태
가장 중요한 단계로는 물론 영속 관계지만 빠르게 각 단계에 대해서 작성하겠다.
비영속
비영속
더 설명할것 없이 객채가 바로 생성된 상태를 뜻한다. 영속성 컨텍스트와 아무관계가 없는 상태
영속
영속
영속 관계이다. 비영속 관계랑은 다르게 회원 객체를 생성하고 엔티티 매니저를 만들고 persist() 단계를 거쳤다. 이 상태에서는 맴버 객체가 엔티티 매니저의 영속 관계에 속해졌다고 보면된다.
영속성 관계에 속해지면은 대표적인 이점들이 있는데 아래와 같다.
각 이점에 대해 간단한 설명을 하겠다.
1차 캐시
1차 캐시 자체가 영속성 관계의 전부라고 볼 수 있다. persist 로 맴버를 영속관계로 지정하는 순간 엔티티매니저는 위와 같은 1차 캐시에 엔티티 객채를 @ID 로 관리하게 된다. 그 후에는 find() 와 같은 매서드를 부르게 되면 1차캐시에 속해있는 엔티티를 우선적으로 확인하고
만약 1차 캐시에 찾고자 하는 엔티티가 없다면은 DB에서 확인 후에 가지고 온다, 그리고 찾아온 멤버는 그대로 1차캐시에 저장이 되서 영속 관계로 가지게 된다.
동일성 보장
1차 캐시로 반복되는 검색을 할 경우에 같은 캐시안에서 같은 데이터를 가지고 오기 때문에 동일성을 보장 할 수 있다.
트랜잭션을 지원하는 쓰기 지연
개인적으로 신기하다고 느꼈던 부분이었다. persist 함수는 꼭 트랜잭션이 끝나고 나가는걸 확인 할 수 있는데 그 이유가 SQL 이 날라가야하는 함수를 쓰게 되면은 쓰기 지연 SQL 저장소라는곳에서 쿼리들을 저장한뒤에 트랜잭션이 commit() 되는 순간 DB로 날라가게 된다고 한다.
변경 감지
JPA 에서 persist() 를 했던 맴버 같은 경우 만약 Setter 같은 방법으로 데이터를 업데이트 해도 자동으로 쿼리가 나간다. 처음 이 방법을 봤을때는 구조가 되게 궁금했었는데 위와 같은 방식으로 이루어진다 했다.
트랜잭션이 커밋되는 순간 1차 캐시에서 가지고 있었던 엔티티와 스냅샷을 비교한뒤에 바뀐 부분이 확인되면 DB에 자동으로 UPDATE 쿼리가 날라간다 한다. 굉장히 편리한 기능이다.
준영속, 삭제
준영속, 삭제
위에 설명과 같다.
플러시
플러시
영속성 컨텍스트 안에서 이루어지는 SQL 쿼리들은 위에 설명했던데로 쓰기지연 SQL 저장소에서 트랜잭션이 commit() 되기 까지 기다리게 된다. 그런데 이런 변경 내용을 강제로라도 DB에 반영시킬 수 있는 방법이 있는데 그것을 플러시 라고 한다.
위에 설명과 같이 flush() 를 직접 호출 할 수도 있고 커밋될때 자동으로 나가는 경우도 있고 JPQL 을 호출 할때는 자동으로 실행이 된다 한다. 이것도 이해가 가능한게 JPQL 로 어떤 데이터를 조회할 경우 그 데이터가 DB 혹은 1차캐시에 있어야 하기 때문에 JPA 입장에서는 강제로라도 flush() 를 날린다고 생각할 수 있겠다.
플러시의 대한 요약을 마무리로 포스트를 끝내겠다.
