[3장] 영속성 관리

개요

EntityManager는 이름 그대로 엔티티를 관리하는 관리자로 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리합니다.

개발자 입장에서 EntityManager는 엔티티를 저장하는 가상의 데이터베이스로 생각하면 됩니다.

 

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

• 복습하자면 EntityManagerFactory를 생성하는 비용은 비싼 편에 속하기 때문에 데이터베이스를 하나만 사용하는 애플리케이션은 일반적으로 EntityManagerFactory를 빈으로 등록하여 하나만 생성
  • EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook")

 

• 그리고 필요할 때마다 EntityManagerFactory에서 EntityManager를 생성하면 됨
  • EntityManager em = emf.createEntityManager();
  • EntityManagerFactory와 달리 EntityManager를 생성하는 비용은 거의 안 듦

 

• EntityManagerFactory는 여러 쓰레드가 동시에 접근해도 안전하므로 서로 다른 쓰레드 간에 공유해도 되지만, EntityManager는 여러 쓰레드가 동시에 접근하면 동시성 문제가 발생하므로 쓰레드 간 절대 공유하면 안 됨

 

https://cornswrold.tistory.com/337

 

부연 설명

• EntityManagerFactory에서 다수의 EntityManager를 생성
• EntityManager는 데이터베이스 연결이 꼭 필요한 시점까지 커넥션을 얻지 않음 (EntityManager1)
• EntityManager는 트랜잭션을 시작할 때 커넥션을 획득 (EntityManager2) 

 

영속성 컨텍스트 (PersistenceContext)

• 직독직해하면 `엔티티를 영구 저장하는 환경`이라는 뜻으로 논리적인 개념에 가까워 눈에 보이지 않음
• 영속성 컨텍스트는 EntityManager를 생성할 때 하나 만들어지며 EntityManager를 통해 영속성 컨텍스트에 접근 및 관리 가능
• EntityManager로 엔티티를 저장하거나 조회할 경우 EntityManager는 영속성 컨텍스트에 엔티티를 보관하고 관리함
  • persist() 메서드는 EntityManager를 사용해서 회원 엔티티를 영속성 컨텍스트에 저장함

 

엔티티의 생명주기

엔티티에는 다음과 같이 네 가지 상태가 존재합니다.

• 비영속 (new/transient): 영속성 컨텍스트와 전혀 관계가 없는 상태
• 영속 (managed): 영속성 컨텍스트에 저장된 상태
• 준영속 (detached): 영속성 컨텍스트에 저장되었다가 분리된 상태
• 삭제 (removed): 삭제된 상태

 

https://www.objectdb.com/java/jpa/persistence/managed

 

1. 비영속 (new/transient)

• 아직 저장하지 않은 엔티티 객체로 순수한 객체 상태
• 영속성 컨텍스트나 데이터베이스와는 전혀 관련이 없는 상태

 

2. 영속 (managed)

• 영속성 컨텍스트가 관리하는 엔티티를 영속 상태라 부름
• 영속 상태라는 것은 영속성 컨텍스트에 의해 관리된다는 뜻
• em.find()나 JPQL을 사용해서 조회한 엔티티도 영속성 컨텍스트가 관리하는 영속 상태

 

3. 준영속 (detached)

• 영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 영속성 컨텍스트가 관리하지 않으면 준영속 상태
• 특정 엔티티를 준영속 상태로 만들려면 em.detach()를 호출하면 됨
• em.close()를 호출해서 영속성 컨텍스트를 닫거나 em.clear()를 호출해서 영속성 컨텍스트를 초기화해도 영속성 컨텍스트가 관리하던 영속 상태의 엔티티는 준영속 상태가 됨
• ex) 이미 영속성 컨텍스트에 존재하던 엔티티가 분리(detached)된 상태에서, 이를 다른 엔티티와 연관관계로 옮겨 저장하려 할 때에도 에러가 발생할 수 있음

 

4. 삭제 (removed)

• 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제

 

영속성 컨텍스트의 특징

영속성 컨텍스트의 특징은 다음과 같습니다.

• 영속성 컨텍스트와 식별자 값: 영속성 컨텍스트는 엔티티를 @Id로 매핑한 식별자 값으로 구분하기 때문에 영속 상태는 식별자 값이 반드시 있어야 함
• 영속성 컨텍스트와 데이터베이스 저장: JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는데 이것을 flush라 함
• 영속성 컨텍스트가 엔티티를 관리할 경우 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 그리고 지연 로딩과 같은 장점이 있음

 

1. 엔티티 조회

• 영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이것을 1차 캐시라고 부르고 영속 상태의 엔티티는 모두 이곳에 저장됨
  • 영속성 컨텍스트 내부에 Map이 하나 있는데 key는 @Id로 매핑한 식별자고 value는 엔티티 인스턴스
  • 따라서 영속성 컨텍스트에 데이터를 저장하고 조회하는 모든 기준은 데이터베이스 기본 키 값
  • 엔티티들을 조회할 때 메모리에 있는 1차 캐시에서 바로 불러오므로 성능상 이점을 누릴 수 있음

 

 

부연 설명

• 위 코드를 실행하면 1차 캐시에 회원 엔티티를 저장하지만 아직 데이터베이스에 저장되지 않은 상태

 

https://escapefromcoding.tistory.com/381

 

1.1 1차 캐시에서 조회

• em.find() 메서드를 호출하면 먼저 1차 캐시에서 엔티티를 조회하고 만약 찾는 엔티티가 1차 캐시에 없으면 데이터베이스에서 조회함

 

 

부연 설명

• 위 코드에서 em.find()는 1차 캐시에서 엔티티를 조회함

 

https://escapefromcoding.tistory.com/381

 

 

1.2 데이터베이스에서 조회

• 앞서 설명했다시피 em.find()를 호출했는데 엔티티가 1차 캐시에 없을 경우 EntityManager는 데이터베이스를 조회해서 엔티티를 생성한 뒤 1차 캐시에 저장한 후에 영속 상태의 엔티티를 반환함

 

 

부연 설명

• em.find(Member.class, "member2")를 실행했을 때 member2가 1차 캐시에 없으므로 데이터베이스에서 조회
• 조회한 데이터로 member2 엔티티를 생성해서 1차 캐시에 저장 (영속 상태)
• 조회한 엔티티를 반환

 

https://escapefromcoding.tistory.com/381

 

1.3 영속 엔티티의 동일성 보장

 

 

부연 설명

• em.find(Member.class, "member1")를 반복해서 호출해도 영속성 컨텍스트는 1차 캐시에 있는 같은 엔티티 인스턴스 반환하기 때문에 둘은 같은 인스턴스고 결과는 당연히 참
• 영속성 컨텍스트는 성능상 이점과 엔티티의 동일성을 보장
• JPA는 1차 캐시를 통해 반복 가능한 읽기 (REPEATABLE READ) 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공한다는 장점이 있음

 

2. 엔티티 등록

 

 

부연 설명

• EntityManager는 트랜잭션을 커밋하기 직전까지 DB에 엔티티를 저장하지 않고 내부 쿼리 저장소에 INSERT SQL을 모아둔 뒤 트랜잭션을 커밋할 때 모아둔 쿼리를 DB에 보냄
  • 이것을 트랜잭션을 지원하는 쓰기 지연 (transaction with write-behind)이라고 부름

 

https://escapefromcoding.tistory.com/381

 

부연 설명

• 먼저 회원 A를 영속화했고 영속성 컨텍스트는 1차 캐시에 회원 엔티티를 저장하면서 동시에 회원 엔티티 정보로 INSERT 쿼리를 만들었고 만들어진 등록 쿼리를 쓰기 지연 SQL 저장소에 보관함
• 마찬가지로 회원 B에 대해서도 동일한 작업을 진행하여 쓰기 지연 SQL 저장소에 등록 쿼리가 2건 저장됨
• 트랜잭션을 커밋하면 EntityManager는 우선 영속성 컨텍스트를 flush 함
  • flush는 영속성 컨텍스트의 변경 내용을 DB에 동기화하는 작업인데 이때 등록, 수정, 삭제한 엔티티를 DB에 반영함
  • 쓰기 지연 SQL 저장소에 모인 쿼리를 데이터베이스에 보냄

 

3. 엔티티 수정

 

3.1 SQL 수정 쿼리의 문제점

• SQL을 사용하면 수정 쿼리를 직접 작성해야 하는데 작성해야 하는 쿼리가 프로젝트 규모에 비례하여 추가됨
  • 이런 개발 방식을 적용하면 수정 쿼리가 많아지는 것은 물론이고 비즈니스 로직을 분석하기 위해 SQL을 계속 확인해야 하기 때문에 결국 직접적이든 간접적이든 비즈니스 로직이 SQL에 의존하게 됨

 

3.2 변경 감지 (Dirty Checking)

 

 

부연 설명

• JPA로 엔티티를 수정할 때는 단순히 엔티티를 조회해서 데이터만 변경하면 됨
  • 명시적으로 update() 메서드를 호출하지 않아도 됨

 

• 이렇게 엔티티의 변경사항을 DB에 자동으로 반영하는 기능을 변경 감지라 부름
  • JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해서 저장해 두는데 이것을 스냅샷이라 하며 flush 시점에 스냅샷과 엔티티를 비교해서 변경된 엔티티를 찾음
  • 주의할 점은 변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용된다는 점 (비영속, 준영속처럼 영속성 컨텍스트의 관리를 받지 못하는 엔티티는 값을 변경해도 데이터베이스에 반영되지 않음)

 

• setter 메서드를 통해 name과 age만 변경했으므로 변경 감지로 인해 실행된 UPDATE SQL은 NAME과 AGE 컬럼 값만 변경한다고 생각할 수 있지만 JPA의 기본 전략은 엔티티의 모든 필드를 업데이트함
  • 이렇게 모든 필드를 사용하면 데이터베이스에 보내는 데이터 전송량이 증가하는 단점이 있지만
  • 바인딩되는 데이터는 다르더라도 UPDATE 쿼리 틀을 항상 같게 가져가 애플리케이션 로딩 시점에 UPDATE 쿼리를 미리 생성해 두고 재사용할 수 있고
  • DB에 동일한 쿼리를 보내면 데이터베이스는 이전에 한 번 파싱 된 쿼리를 재사용할 수 있음

 

• 만약 필드가 많거나 저장되는 내용이 너무 클 경우 수정된 데이터만 사용해서 동적으로 UPDATE SQL을 생성하는 전략인 DynamicUpdate 전략을 채택하면 됨
  • 단 이때는 hibernate 확장 기능을 사용해 org.hibernate.annotations.DynamicUpdate 어노테이션을 적용
  • 컬럼이 대략 30개 이상이 되면 기본 방법인 정적 수정 쿼리보다 @DynamicUpdate를 사용한 동적 수정 쿼리가 빠르다고 함

 

https://escapefromcoding.tistory.com/381

 

부연 설명

• 트랜잭션을 커밋하면 EntityManager 내부에서 먼저 flush()가 호출됨
• 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾음
• 변경된 엔티티가 있으면 UPDATE 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보냄
• 쓰기 지연 저장소의 SQL을 데이터베이스에 보냄
• 데이터베이스 트랜잭션을 커밋함

 

4. 엔티티 삭제

 

 

부연 설명

• 엔티티를 삭제하려면 먼저 삭제 대상 엔티티를 조회해야 함
• em.remove()에 삭제 대상 엔티티를 넘겨주면 엔티티를 즉시 삭제하는 것이 아니라 엔티티 등록과 비슷하게 삭제 쿼리를 쓰기 지연 SQL 저장소에 등록
  • em.remove(memberA)를 호출하는 순간 memberA는 영속성 컨텍스트에서 제거됨
  • 따라서 삭제된 엔티티는 재사용하지 말고 GC의 대상이 되도록 두는 것이 좋음

 

• 이후 트랜잭션을 커밋해서 flush를 호출하면 실제 데이터베이스에 삭제 쿼리를 전달함

 

5. 플러시

• flush()는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영
  • 이름만 보고 영속성 컨텍스트에 보관된 엔티티를 지운다고 생각하면 안 됨
  • 변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 조회하며 수정된 엔티티는 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 등록함
  • 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송

 

• 영속성 컨텍스트를 flush하는 방법은 다음과 같이 세 가지
  • em.flush()를 직접 호출
  • 트랜잭션 커밋 시 flush가 자동 호출
  • JPQL 쿼리 실행 시 flush가 자동 호출

 

5.1 직접 호출

• EntityManager의 flush() 메서드를 직접 호출해서 영속성 컨텍스트를 강제로 flush
• 테스트나 다른 프레임워크와 JPA를 함께 사용할 때를 제외하고 거의 사용하지 않음

 

5.2 트랜잭션 커밋 시 flush 자동 호출

• DB에 변경 내용을 SQL로 전달하지 않고 트랜잭션만 커밋할 경우 어떤 데이터도 DB에 반영되지 않음
• 따라서 트랜잭션을 커밋하기 전에 꼭 flush를 호출해서 영속성 컨텍스트의 변경 내용을 DB에 반영해야 함
  • JPA는 위와 같은 문제를 방지하고자 트랜잭션을 커밋할 때 flush를 자동으로 호출함

 

5.3 JPQL 쿼리 실행 시 flush 자동 호출

• JPQL이나 Criteria 같은 객체지향 쿼리를 호출할 때도 flush가 실행됨

 

 

부연 설명

• em.persist()를 호출해서 엔티티 memberA, memberB, memberC를 영속 상태로 만들었고 해당 엔티티들은 영속성 컨텍스트에 있지만 아직 데이터베이스에 반영되지 않았음
• 이런 상태에서 JPQL은 SQL로 변환되어 데이터베이스에서 엔티티를 조회하는데 memberA, memberB, memberC는 아직 데이터베이스에 없으므로 쿼리 결과로 조회되지 않음
  • 따라서 쿼리를 실행하기 직전에 영속성 컨텍스트를 flush 해서 변경 내용을 데이터베이스에 반영해야 함
  • JPA는 이런 문제를 예방하기 위해  JPQL을 실행할 때도 flush를 자동 호출함
  • 식별자 기준으로 조회하는 find() 메서드를 호출할 때는 flush가 실행되지 않음 (1차 캐시에서 조회)

 

5.4 flush 모드 옵션

• EntityManager에 flush 모드를 직접 지정하려면 javax.persistence.FlushModeType을 사용하면 됨
  • FlushModeType.AUTO: 커밋이나 쿼리를 실행할 때 flush (default 값)
  • FlushModeType.COMMIT: 커밋할 때만 flush

 

6. 준영속

• 영속성 컨텍스트가 관리하는 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 것을 준영속 상태라고 부름
• 준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없음
• 영속 상태의 엔티티를 준영속 상태로 만드는 방법은 다음과 같이 크게 세 가지
  • em.detach(entity): 특정 엔티티만 준영속 상태로 전환함
  • em.clear(): 영속성 컨텍스트를 완전히 초기화
  • em.close(): 영속성 컨텍스트를 종료함

 

6.1 엔티티를 준영속 상태로 전환: detach()

• em.detach() 메서드는 특정 엔티티를 준영속 상태로 만듦

 

부연 설명

• detach() 메서드를 호출하는 순간 1차 캐시부터 쓰기 지연 SQL 저장소까지 해당 엔티티를 관리하기 위한 모든 정보가 제거됨
• 복습하자면 영속 상태였다가 더는 영속성 컨텍스트가 관리하지 않는 상태를 준영속 상태라고 함
  • 이미 준영속 상태이므로 영속성 컨텍스트가 지원하는 어떤 기능도 동작하지 않음
  • 심지어 쓰기 지연 SQL 저장소의 INSERT SQL도 제거되어 데이터베이스에 저장되지도 않음

 

6.2 영속성 컨텍스트 초기화: clear()

• em.clear()는 영속성 컨텍스트를 초기화해서 해당 영속성 컨텍스트의 모든 엔티티를 준영속 상태로 만듦
  • 반면, em.detach()는 특정 엔티티 하나를 준영속 상태로 만듦

 

부연 설명

• clear()를 호출하면 영속성 컨텍스트를 제거하고 새로 만드는 것과 같음
• memberA는 영속성 컨텍스트가 관리하지 않으므로 준영속 상태
  • 준영속 상태이므로 영속성 컨텍스트가 지원하는 변경 감지가 동작하지 않아 회원의 이름을 변경해도 DB에 반영 X

 

6.3 영속성 컨텍스트 종료: close()

• 영속성 컨텍스트를 종료하면 해당 영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 모두 준영속 상태

 

부연 설명

• 영속성 컨텍스트가 종료되어 더는 memberA, memberB가 관리되지 않음

 

6.4 준영속 상태의 특징

준영속 상태인 회원 엔티티는 다음과 같이 됩니다.

• 거의 비영속 상태에 가깝다: 영속성 컨텍스트가 관리하지 않으므로 1차 캐시, 쓰기 지연, 변경 감지 및 지연 로딩을 포함한 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않음 
• 식별자 값을 가지고 있다: 비영속 상태는 식별자 값이 없을 수도 있지만 준영속 상태는 이미 한 번 영속 상태였으므로 반드시 식별자 값을 가지고 있음
• 지연 로딩을 할 수 없다: 지연 로딩은 실제 객체 대신 프록시 객체를 로딩해 두고 해당 객체를 실제 사용할 때 영속성 컨텍스트를 통해 데이터를 불러오는 방법이지만 준영속 상태는 영속성 컨텍스트가 더는 관리하지 않으므로 지연 로딩 시 문제가 발생함

 

6.5 병합: merge()

• merge() 메서드는 준영속 상태의 엔티티를 받아서 해당 정보로 새로운 영속 상태의 엔티티를 반환함

 

6.5.1 준영속 병합

 

부연 설명

• mergeMember() 메서드에서 새로운 영속성 컨텍스트를 시작하고 em2.merge(member)를 호출해서 준영속 상태의 member 엔티티를 영속성 컨텍스트가 관리하는 영속 상태로 변경
  • 영속 상태이므로 트랜잭션을 커밋할 때 수정했던 회원명이 데이터베이스에 반영됨

 

• merge()는 파라미터로 넘어온 준영속 엔티티를 사용해서 새롭게 병합된 영속 상태의 엔티티를 반환
  • 파라미터로 넘어온 엔티티는 병합 후에도 준영속 상태로 남아 있음

 

6.5.2 비영속 병합

• 병합은 비영속 엔티티도 영속 상태로 만들 수 있음

 

부연 설명

• 병합은 파라미터로 넘어온 엔티티의 식별자 값으로 영속성 컨텍스트를 조회하고 찾는 엔티티가 없으면 데이터베이스에서 조회
  • 만약 데이터베이스에서도 발견하지 못하면 새로운 엔티티를 생성해서 병합

 

• 정리하면 병합은 준영속, 비영속을 신경 쓰지 않으며 식별자 값으로 엔티티를 조회할 수 있으면 불러서 병합하고 조회할 수 없으면 새로 생성해서 병합함

 

참고

자바 ORM 표준 JPA 프로그래밍 - 김영한 저