JPA - 영속성 컨텍스트와 JPQL

쿼리 후 영속 상태인 것과 아닌것

-JPQL의 조회 대상은 엔티티, 임베디드 타입, 값 타입 같이 다양하다. 하지만 엔티티를 조회하면 영속성 컨텍스트에 관리되지만 나머지는 관리되지 않는다. 예를 들어 임베디드 타입만 참조해서 조회했을 경우에 값을 변경해서 플러시 시점에 반영되지 않는다. 하지만 엔티티를 조회하여 엔티티가 가지고 있는 임베디드타입을 변경했을 경우에는 플러시 시점에 변경이 반영이 된다.

JPQL로 조회한 엔티티와 영속성 컨텍스트

JPQL과 플러시 모드

JPQL은 영속성 컨텍스트에 있는 데이터를 고려하지 않고 디비에서 데이터를 조회한다. 따라서 JPQL을 실행하기 전에 영속성 컨텍스트의 내용을 디비에 반영해야한다. 그렇지 않으면 의도하지 않은 결과가 발생할 수 있다.

이 예제는 QueryDSL의 수정 배치 쿼리이다. 이 예제의 결과가 어떻게 될것인가? 결과는 정말 의도치 않게 나오게 된다. QueryDSL의 배치쿼리는 영속성컨텍스트와 관계없이 직접 디비로 요청을 보내게 된다. 이러는 순간 디비와 영속성컨텍스트의 동기화는 깨진것이다. 변경을 완료했고 나는 변경된 이름으로 쿼리를 날렸는데, 이게 뭐람 변경전의 "여성게1"이란 결과가 나오게 된다. 이유는 위에서 설명한 것과 같이 영속성컨텍스트에 이미 존재하기 때문에 디비에서 가져온 엔티티가 데이터가 달라도 식별자 값이 같기 때문에 버려지게 되고 수정전에 이름이 출력되게 되는 것이다.

이 코드는 실무에서는 사용할 수없는 코드이다. 하지만 직관적으로 영속성 컨텍스트의 값을 수정배치쿼리와 동일하게 변경한것을 보여주기 위해 짠것이다. 이 예제의 결과는 수정배치에서 변경된 값과 동일한 엔티티가 반환되게 된다.

JPA 영속성 관리 - persistence context(영속성컨텍스트)

JPA가 제공하는 기능은 크게 엔티티와 테이블을 매핑하는 설계부분과 매핑한 엔티티를 실제 사용하는 부분으로 나눌 수 있다.

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

EntityManager는 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리한다. 이름 그대로 엔티티를 관리하는 관리자다. 개발자 입장에서 엔티티 매니저는 엔티티를 저장하는 가상의 데이터베이스로 생각하면 될 듯 싶다.

그러면 엔티티 매니저 팩토리란 무엇인가? 바로 이 엔티티 매니저를 생성해주는 공장역할을 하는 객체이다. 보통 엔티티 매니저 팩토리는 생성비용이 크게 때문에 하나만 생성해서 모든 스레드가 공유할 수 있도록 설계되었고, 엔티티 매니저는 사용할 때마다 새로 생성하면 된다. 즉, 엔티티 매니저는 데이터베이스 커넥션과 관련이 있는 객체이기에 스레드간 공유가 되서는 안되는 객체이다. 이 엔티티 매니저는 데이터베이스와 커넥션을 맺지만 꼭 필요할 때 커넥션을 맺는다.(트랜잭션이 시작되었을 경우) 

Ex) EntityManagerFactory emf = Persistence.createEntityManagerFactory("persist"); -> "persist"는 persistence.xml에 생성한 persistence unit 명이다.

      EntityManager em = ema.createEntityManager();

영속성 컨텍스트란?

영속성 컨텍스트란 JPA에서 가장 중요한 용어 중 하나이다. 이것을 한글로 표현하면 "엔티티를 영구 저장하는 환경"이라고 표현해도 좋을 것 같다. 즉, 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.

em.persist(entity)는 실제로 데이터베이스에 회원 엔티티를 저장하는 것이 아니고, 엔티티 매니저를 사용해 엔티티를 영속성 컨텍스트에 저장하는 것이다.

엔티티의 생명주기

비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태이다.

영속: 영속성 컨테스트에 저장된 상태

준영속: 영속성 컨텍스트에 저장되었다가 분리된 상태

삭제: 삭제된 상태

비영속 상태를 예를 들면 엔티티 객체를 생성한 상태이다.

Member m = new Member(); -> 지금 이 상태는 순수한 객체 상태이며, 아직 저장하지 않은 것이라서 영속성 컨텍스트나 데이터베이스와는 전혀 관련이 없는 것이다.

영속 상태를 예를 들면 em.persist(entity) 혹은 em.find(entity) 등을 호출한 상태이며, 이 상태는 영속성 컨테스트가 관리하는 엔티티가 되었다 라는 뜻이다. 

준영속 상태는 영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 영속성 컨텍스트가 관리하지 않는 상태를 말한다. 예를 들면, em.detach(),em.close(),em.clear() 등 분리,닫기,초기화 등의 메소드를 호출하게 되면 영속된 엔티티들은 모두 준영속 상태가 된다.

삭제 상태는 말그대로 영속성 컨텍스트(+데이터베이스)에서 상태가 되는 것이다. em.remove(entity)

영속성 컨텍스트의 특징

1)영속성 컨텍스트와 식별자 값 - 영속성 컨텍스트는 엔티티를 식별자 값(@Id로 테이블의 기본키와 매핑한 값)으로 구분한다. 즉, 영속상태에 있으려면 반드시 식별자 값이 존재해야한다. 만약 식별자 값이 없다면 예외가 발생하게 된다.

2)JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는 데, 이것을 Flush라고 한다.

영속성 컨텍스트가 엔티티를 관리하면서의 장점

-1차 캐시 : persist메소드를 호출하면 commit이 호출되기 전까지 1차 캐시에 저장된다. 즉, find 메소드를 호출하면 데이터베이스에서 직접 엑세스해서 가져오는 것이 아니라, 메모리의 캐시에서 엔티티를 가져오게 되므로 빠른 속도와 적은 비용으로 조회가 가능하다.

-동일성 보장 : 아무리 같은 엔티티 키값으로 여러번 조회를 해도 1차 캐시에서 하나의 객체만 리턴해주기 때문에 항상 동일성을 보장한다.(같은 인스턴스를 가르킨다.)

-트랜잭션을 지원하는 쓰기 지연 : JPA는 commit 호출전까지 데이터베이스에 쓰기를 하지 않는다. 그말은 쿼리를 쿼리 저장소에 차곡차곡 모아두다가 commit이 되는 시점에 모아둔 모든 쿼리를 데이터베이스에 반영하는 지연작업을 한다.

-변경 감지:ex) Member m = em.find(Member.class,"1");

                       m.setAge(27);

JPA는 이렇게 set메소드로 데이터만 변경했을 뿐이지만 commit 시점에 데이터베이스의 데이터가 update된다. 왜냐? 영속성 컨텍스트에는 항상 엔티티의 복사본인 스냅샵을 가지고 있기 때문에 commit 시점에 스냅샵과 현재 엔티티의 값을 비교해 다른 점이 있다면 update쿼리를 쿼리저장소에 보내서 commit될때 데이터베이스에 반영이 된다. 하지만 가정이 있다. 반드시 영속상태의 엔티티만 적용이 된다는 것이다.

업데이트 쿼리는 모든 필드를 대상으로 업데이트를 한다.(수정 쿼리가 항상 같기에 애플리케이션 로딩시점에 수정 쿼리를 미리 생성해두고 재사용 할 수 있고, 데이터베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 한번 파싱된 쿼리를 재사용한다.) 물론 변경된 대상으로만 update쿼리를 보내는 방법도 있는데 이것은 hibernate 확장기능을 이용해야한다(DynamicUpdate,DynamicInsert..)

-지연 로딩: