JPA 영속성 관리와 영속성 컨텍스트

1. Entity Manager Factory & Entity Manager

애플리케이션이 실행될 때, xml 또는 properties 파일에 있는 정보를 바탕으로 Entity Manager Factory 를 생성한다. Entity Manager Factory를 이용해서

Entity Manager 생성이 가능하다. Entity Manager Factory 는 비용이 많이 소요되기 때문에 하나의 애플리케이션에서 공유해서 사용이 가능하고,

멀티스레드에서도 동기화 처리를 통해 안전하게 사용이 가능하다. 하지만 Entity Manager는 여러 스레드에서 공유해서 사용되서는 안되기 때문에

스레드마다 Entity Manager를 생성할 필요가 있다. 아래는 SPRING BOOT에서 JPA Database 설정을 위한 properties 파일이다.

아래 속성에 대한 자세한 설명은 다음 사이트를 참고한다. 

https://docs.jboss.org/hibernate/orm/3.3/reference/en-US/html/session-configuration.html#configuration-optional 

            
spring.datasource.url=jdbc:h2:mem://localhost/~/java-qna-atdd;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect

2. 영속성 컨텍스트

JPA에서 가장 중요한 영속성 컨텍스트는 엔티티를 영구 저장하는 환경이라는 뜻이다. 엔티티 매니저를 생성하면 영속성 컨텍스트가 자동으로 생성되고, 

Entity Manager를 이용해서 영속성 컨텍스트에 엔티티를 보관/관리한다. 엔티티는 4가지 속성을 가지고 있다.

영속성 컨텍스트는 엔티티를 @Id(기본키)로 구분하기 때문에 영속 상태는 반드시 식별자를 가지고 있어야만 한다.

 - 비영속 : 영속성 컨텍스트와 전혀 무관한 상태로 순수한 객체의 상태 (처음 객체가 생성되면 비영속 상태)

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

 - 준영속 : 영속성 컨텍스트에서 관리하다, 영속성 컨텍스에서 분리된 상태, 준영속 상태는 영속 상태 였던 적이 있기 때문에 @Id 값을 반드시 가지고 있다.

              하지만, 비영속은 순수한 객체의 상태이기 때문에 @Id 값을 안 가지고 있는 경우가 존재할 수 있다. 이것이 유일한 차이점이지 않을까?

 - 삭제 : 삭제된 상태

준영속의 상태의 엔티티는 그럼 언제 사용할까? 만약 영속성 상태의 엔티티의 값을 데이터베이스에 반영하지 않고, 값을 변경하는 경우가 있다고 하자!

영속상태의 엔티티는 변경하면, 커밋시, 스냅샷과 비교했을 때, 변경사항이 감지되기 때문에 데이터베이스에 반영이 될 수 있다. 이럴 경우에는 비영속상태로

변경한 후, 작업이 필요할 것이다. 아직 이와 같은 상황은 아직 경험하지는 못했다.

3. 영속성 컨텍스트 특징

 (1) 1차 캐시

  영속성 컨택스트 내부에는 1차 캐시라고 불리는 캐시를 가지고 있다. 영속상태의 엔티티는 모두 1차 캐시에 저장되고, 1차 캐시는 @Id를 키로 가지고 있는

  Map이 존재한다. 1차 캐시를 이용하면 데이터의 결과를 빠르게 얻을 수 있는 장점을 가지고 있다. member 엔티티를 조회할 때, 바로 데이터베이스에서 직접

  조회하는 것이 아니고, 우선적으로 1차 캐시에 member 엔티티가 있는지 @Id값으로 확인을 한 후에 엔티티가 있을 떄는 1차 캐시에서 엔티티가 없을 때는 

  데이터베이스에서 조회를 한 후, 1차 캐시에 저장하고, 1차 캐시에서 엔티티를 전달한다. 요약하면, 1차캐시를 우선으로 확인하고, 데이터베이스를 조회한다.

 

 (2) 동일성 보장

  엔티티를 조회할 때, 1차 캐시에서 모든 엔티티를 가져온다. (엔티티 조회 시, 1차캐시에 엔티티가 있다면, 1차캐시에서 곧바로, 없다면 데이터베이스에서

  조회 후, 1차 캐시에 저장하고, 1차 캐시에서 전달) 결국은 모든 엔티티는 최종적으로 1차 캐시에서 가져오므로 식별자가 동일한 엔티티는 동일성 보장된다.

  여기서 동일성이라고 한다면, 자바의 '==' 를 의미(동일한 객체를 참조)이다.

 (3) 트랜잭션을 지원하는 쓰기지연

  트랜잭션은 데이터베이스에서 하나의 작업단위를 의미한다. 영속성 컨텍스트는 삽입/삭제/수정과 같은 DML이 발생했을 때, 바로 데이터베이스에 반영하지
  않고, 트랜잭션을 커밋할 때, 모아둔 쿼리들을 한번에 데이터베이스 반영을 한다. 이것이 쓰기 지연이다. 쿼리들은 영속성 컨텍스트의 쓰기지연SQL 저장소에 
  저장된다. 그리고 커밋을 실행 하면, flush -> commit 순서로 데이터베이스에 작업한다. flush는 쓰기지연SQL 저장소 쿼리들을 데이터베이스에
  저장하는 것이고, commit은 데이터베이스에 쿼리들을 반영하는 것을 의미한다. (commit 실행되면, flush --> commit 순서 실행)

  쓰기지연을 하면, 데이터베이스에 접근하는 횟수가 줄기 때문에 성능면에서 뛰어나다.

 (4) 변경 감지

  영속성 컨텍스트의 1차캐시에는 스냅샷을 통해 엔티티의 변경을 감지한다. 쿼리를 통해 데이터를 조작하는 방법외에도 영속상태의 엔티티의 상태를 

  변경하는 방법으로도 데이터베이스의 데이터를 변경할 수 있다. 변경감지는 아래와 같은 순서로 동작한다.

   a. 트랜잭션을 커밋하면, flush 가 호출되고, 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾는다.

   b. 변경된 엔티티가 존재하면, update 쿼리를 생성해서 쓰기지연SQL 저장소에 저장한다.

   c. 쓰기지연SQL 저장소에 생성된 쿼리들을 데이터베이스에 flush하고 commit 한다.

  변경감지는 오직 영속 상태의 엔티티에만 적용이 된다. 비영속과 준영속은 해당되지 않는다.

  그리고 JPA에서는 엔티티의 특정 필드가 변경되었을 때, 특정 필드만 update 하는 쿼리를 만드는 것이 아닌, 모든 필드를 업데이트 하는 쿼리를 만든다.

  예를들어, 회원정보에서 이메일을 수정할 때, 이메일만을 수정하는 update 쿼리를 만드는 것이 아닌, 이메일, 이름, 패스워드 등 Member 엔티티의 모든

  필드를 수정하는 update 쿼리를 만든다. 왜냐하면, 영속성 컨텍스트에는 쓰기지연SQL 저장소에 쿼리들이 보관되기 때문에 쿼리를 재사용할 수 있다.

  만약 변경된 필드만 update 한다면, Member 엔티티를 update하는 쿼리의 경우의 수가 굉장히 많이 존재할 것이다. 하지만, 모든 필드를 update하는 쿼리가

  존재한다면, 이 쿼리 하나만 있어도 Member 엔티티를 update할 수 있다. 물론 필드의 수가 많다면, 다소 무겁다는 단점이 있을 수 있을 것이다.