[JPA] 영속성 관리 - 내부 동작 방식

 

오늘은 JPA의 영속성 관리에 대해 알아보자.

이전 포스팅과 이어지는 내용이므로

이전 포스팅을 참고하기를 바란다.

 

JPA에서 필수로 알아야 할 단어 중 하나인 '영속성 컨텍스트'에 대해 알아보자.

영속성 컨텍스트란,

엔티티를 영구 저장하는 환경을 의미한다.

EntityManager.persist(entity)로 엔티티를 영속성 컨텍스트에 저장한다.

 

 

엔티티는 생명주기가 있다.

• 비영속(new/transient)
  • 우리가 흔히 new 연산자를 이용해 객체를 생성한 상태는 영속성 컨텍스트와 관계가 없는 새로운 상태를 의미한다.
• 영속(managed)
  • EntityManager.persist(entity)를 하게 되면 영속 상태가 되는데
  • 영속성 컨텍스트에 '관리'되는 상태이다.

 

비영속,영속

위 사진에서 설명한 대로 Member 객체를 생성하고, Id,Name값을 지정해준 부분은

말그래도 객체 '생성'이기 때문에

비영속 상태이다.

 

em.persist(member) 코드를 사용한 이 부분에서

영속 상태가 된다.

 

 

🤔 자 그럼 여기서 질문 하나를 던져보겠다.

em.persist(member) 하고 나서

영속 상태가 되면 db에 쿼리가 날아갈까?

 

 

정답은 디비에 쿼리는 날아가지 않는다!

 

우선 이유를 알기 전에 눈으로 확인해보자.

 

영속 상태의 디비 쿼리문 실행은 언제될까?

 

우선 위의 파란 밑줄로 BEFORE, AFTER 출력문을 만들었다.

 

만약, 영속 상태에 디비에 쿼리가 날아가는 것이 맞다면

BEFORE와 AFTER 출력문 사이에 DB 쿼리가 작성될 것이다.

 

이제 우리는 궁금증을 갖고

cmd를 보자.

 

영속 상태의 cmd

 

보이는 대로 BEFORE와 AFTER 사이에는 DB 쿼리가 작성되지 않았다.

 

 

 

⁉ 그렇다면 DB쿼리는 언제 작성될까?

트랜잭션 커밋

DB 쿼리는 트랜잭션을 커밋할 때 작성된다.

 

 

---

다음으로, 영속성 컨텍스트의 조회에 대해 알아보자.

 

조회하기 전에 

Member를 먼저 등록하고,

Member 등록

 

영속성 컨텍스트의 조회

🤔 em.find()를 이용하여 findMember객체를 만들어

객체를 조회하면 어떻게 될까?

 

아마 많은 사람이 select 문을 이용하여

조회할 것이라 예상할 텐데,

어떻게 나올지 기대하며 cmd를 보자.

 

 

조회 결과

 

보이는가?

우리가 예상했던 바와 달리 sql은

insert밖에 날아가지 않았다.

(insert의 경우 위의 멤버 객체 생성 때문에 나타나는 것)

그래서 결론은 insert 쿼리 날아가고

select 쿼리도 날아갈 거라 예상했지만

select 쿼리는 날아가지 않았다!

 

🤔 왜 select 쿼리는 날아가지 않았을까?

 

위의 em.persist(member)로 

객체를 생성하면서

객체가 1차 캐시에 저장되어 있었기 때문에

DB 값을 조회한 것이 아닌

1차 캐시의 값을 조회한 것!

 

 

다시 한 번 확인해보자

두 번 조회 (1차 캐시 확인)

이제 우리는

findMember1로 처음 조회할 때는 DB에서 값을 가져와야 하고,

findMember2를 조회할 때는 1차 캐시의 값을 조회해야한다는 것을 안다.

 

그럼 확인해보자.

한 번 조회 확인

보이는가?

정말 한 번만 조회한다.

 

 

 

JPA의 영속 엔티티 동일성 보장에 대해서 알아보자.

 

먼저 바로 위의 코드에서 다음과 같은 문장을 실행하면 값은 어떻게 될까?

findMember1==findMember2 결과 확인

 

결과

 

결과는 true이다.

따라서 JPA는 영속 엔티티의 동일성을 보장해준다.

 

 

 

• 참고
  • 인프런 김영한t 자바 ORM 표준 JPA 프로그래밍 강의