[JPA] 3장. 영속성 관리

[tonykang22]

3장. 영속성 관리

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

일반적인 웹 애플리케이션

• 엔티티 매니저 팩토리는 생성 비용이 매우 크기 때문에 애플리케이션에서 하나의 데이터베이스를 사용한다면 단 한 개만 생성한다.
  • 그와 달리 엔티티 매니저는 생성 비용이 거의 들지 않는다.
• 엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하므로 서로 다른 스레드 간에 공유해도 된다.
  • 엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생하기 때문에 스레드 간에 절대 공유하면 안된다.
• 엔티티 매니저는 데이터베이스 연결이 꼭 필요한 시점까지 커넥션을 얻지 않는다.
  • 보통 트랜잭션을 시작할 때 커넥션을 획득한다.

영속성 컨텍스트란?

• 영속성 컨텍스트(Persistence Context)라는 용어가 JPA를 이해하는데 가장 중요한 키워드라 할 수 있다.
• 엔티티를 영구 저장하는 환경이라는 뜻으로 번역할 수 있다.
• 즉, 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.
  • em.persist(member)는 회원 엔티티를 저장 한다라고 생각하면 정확한 이해는 아니다.
  • 정확한 의미는 엔티티 매니저를 사용해 회원 엔티티를 영속성 컨텍스트에 저장한다. 이다.
• 영속성 컨텍스는 논리적인 개념이다.
  • 엔티티 매니저를 생성할 때 하나가 만들어진다.
  • 엔티티 매니저를 통해 영속성 컨텍스트에 접근할 수 있고 영속성 컨텍스트를 관리할 수 있다.
    • 여러 엔티티 매니저가 같은 영속성 컨텍스트에 접근할 수도 있다.

엔티티의 생명주기

엔티티의 생명주기

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

비영속

em.persist() 호출 전

• 엔티티 객체를 생성했으나 아직 저장하지 않은 상태
  • 영속성 컨텍스트나 데이터베이스와 전혀 관련이 없는 상태이다.

영속

em.persist() 호출 후

• 엔티티 매니저를 통해 엔티티를 영속성 컨텍스트에 저장한 상태
  • 영속성 컨텍스트가 관리하는 엔티티를 영속 상태라고 한다.

준영속

• 영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 영속성 컨텍스트가 더 이상 관리하지 않는 상태
  • 특정 엔티티를 준영속 상태로 만드려면 em.detach(); 호출을 하면 된다.
  • 영속성 컨텍스트를 닫거나 (em.close();), 영속성 컨텍스트를 초기화해도 (em.clear();) 관리되던 엔티티는 준영속 상태가 된다.

삭제

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

영속성 컨텍스트의 특징

• 영속성 컨텍스트는 엔티티를 식별자 값으로 구분한다.
  • 즉, 영속 상태는 식별자 값이 반드시 있어야 한다.
    • 없으면 예외가 발생한다.
• 영속성 컨텍스트와 데이터베이스 저장
  • JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영한다.
    • 이를 flush라 한다.
• 영속성 컨텍스트가 엔티티를 관리해서 얻는 장점
  • 1차 캐시
  • 동일성 보장
  • 트랜잭션을 지원하는 쓰기 지연
  • 변경 감지
  • 지연 로딩

엔티티 조회

• 영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이를 1차 캐시라 한다.
  • 영속 상태인 모든 엔티티가 이 곳에 저장된다.
  • 이해를 돕기 위해, 영속성 컨텍스트 내부에 Map이 존재하는데 키는 @Id로 매핑한 식별자, 값은 엔티티 인스턴스라고 생각하면 된다.
  • 영속성 컨텍스트에서 데이터를 저장 및 조회하는 기준은 데이터베이스 기본 키 값이다.

• 먼저 엔티티를 생성해 영속 상태로 변경해보자.

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

• 이번엔 엔티티를 조회해보자.
  • em.find()를 호출하면 먼저 1차 캐시에서 엔티티를 찾아보고, 없다면 데이터베이스에 조회하게 된다.
  • 데이터베이스에서 조회하게된 경우, 엔티티를 생성해 1차 캐시에 저장한 후에 영속 상태의 엔티티를 반환하게 된다.

• 위와 같은 예시를 통해 알 수 있듯, 영속성 컨텍스트는 성능상 이점과 엔티티의 동일성을 보장한다.

엔티티 등록

• 엔티티 매니저는 트랜잭션이 커밋하기 전까지 내부 쿼리 저장소에 INSER SQL을 모아둔다.
  • 트랜잭션 커밋이 일어나면 모아둔 쿼리를 데이터베이스로 보낸다.
  • 이를 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)이라고 한다.

회원 A를 영속화한 상태

회원 B도 영속화한 상태, 쓰기 지연 SQL 저장소에 쿼리가 쌓인다.

커밋했을 때

• 트랜잭션을 커밋하면 엔티티 매니저는 우선 영속성 컨텍스트를 플러시한다.
  • flush: 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 작업이다.
    • 쓰기 지연 SQL 저장소에 쌓인 쿼리를 데이터베이스에 보낸다는 의미이다.

트랜잭션을 지원하는 쓰기 지연이 가능한 이유

• 위의 코드를 두 가지의 경우로 나눠 생각해보자
  • 1. 데이터를 저장하는 즉시 등록 쿼리를 데이터베이스로 전송한다.
       • 마지막에 트랜잭션을 커밋한다.
  • 2. 데이터를 저장하면 등록 쿼리를 메모리에 모아둔다.
       • 트랜잭션 커밋할 때 모아두었던 등록 쿼리를 데이터베이스에 보낸 후 커밋한다.
• 두 경우 모두 트랜잭션 범위 안에서 실행되므로 결과는 같다.
  • 트랜잭션을 커밋하면 함께 저장되고, 롤백하면 함께 저장되지 않는다.
  • 어떤 방식으로든 커밋 직전에만 데이터베이스에 SQL을 전달하면 된다.
    • 그렇기에 트랜잭션을 지원하는 쓰기 지연이 가능해진다.

엔티티 수정

• SQL을 사용했을 때는, 수정 쿼리를 직접 작성해야했다.
  • 수정 쿼리 또한 점점 추가된다.
  • 수정되는 컬럼의 종류에 따라 쿼리가 변경되기 때문에 쿼리가 많아진다.
  • 비즈니스 로직을 분석하기 위해 SQL을 계속 확인해줘야 한다.
  • 즉, 결국 비즈니스 로직이 SQL에 의존하게 된다.

변경감지

• JPA는 엔티티를 수정할 때 변경감지를 통해 위와 같은 문제점들에서 자유로워진다.
  • 변경 감지(dirty checking): 엔티티의 변경 사항을 데이터베이스에 자동으로 반영하는 기능

• JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해 저장해둔다.
  • 이를 스냅샷이라 한다.
• 플러시 시점에 스냅샷과 엔티티를 비교해 변경된 엔티티를 찾는다.
  • 변경된 엔티티가 있다면 수정 쿼리를 생성해 쓰기 지연 SQL 저장소에 보낸다.
• 변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용된다.
  • 비영속, 준영속 상태의 엔티티는 변경 감지 대상이 아니다.
• 기본적으로 JPA는 변경 감지가 된 엔티티에 대해 모든 필드를 업데이트한다.
  • 데이터 전송량이 증가하는 단점이 존재한다.
  • 그러나 모든 필드를 업데이트하므로서 수정 쿼리가 항상 같게 된다.
    • 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용할 수 있다.
  • 데이터베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 한 번 파싱된 쿼리를 재사용할 수 있다.
  • 물론 이것은 기본 전략으로, 동적으로 수정 쿼리를 생성하는 전략을 선택하는 방법도 존재한다.

엔티티 삭제

• 엔티티를 즉시 삭제하는 것이 아니라 삭제 쿼리를 쓰기 지연 SQL 저장소에 등록한다.
  • 트랜잭션 커밋이 일어나 플러시를 호출하면 그 때 삭제된다.
  • 그러나 em.remove(A)를 호출한 순간 A는 영속성 컨텍스트에서 제거된다.
    • 이렇게 삭제된 엔티티는 재사용하지 말고 GC의 대상이 되도록 두는 것이 좋다.

플러시

• 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.
  • 변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해 수정된 엔티티를 찾는다.
    • 필요한 경우 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 등록한다.
  • 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.
• 영속성 컨텍스트를 플러시하는 방법은 3가지이다.
  • em.flush()를 직접 호출한다.
  • 트랜잭션 커밋 시 플러시가 자동 호출된다.
    • 플러시 호출 없이 트랜잭션 커밋 시 아무런 변경도 데이터베이스에 반영되지 않기 때문에 이런 문제를 예방하기 위해 JPA는 자동 호출하게 했다.
  • JPQL 쿼리 실행 시 플러시가 자동 호출된다.
    • JPQL은 SQL로 변환되어 데이터베이스에서 엔티티를 조회한다.
    • 따라서 쿼리를 실행하기 직전에 영속성 컨텍스트를 플러시해서 변경 내용을 데이터베이스에 반영해야 한다.

플러시 모드 옵션

• javax.persistence.FlushModeType을 통해 엔티티 매니저의 플러시 모드를 직접 지정할 수 있다.
  • FlushModeType.AUTO: 커밋이나 쿼리를 실행할 때 플러시 (기본값)
  • FlushModeType.COMMIT: 커밋할 때만 플러시
• 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 것이 플러시이지,
  • 플러시라는 이름으로 인해 영속성 컨텍스트에 보관된 엔티티를 지운다고 생각하면 안된다.

준영속

• 준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
• 영속 상태의 엔티티를 준영속 상태로 만드는 방법은 크게 3가지이다.
  • em.detach(A): 특정 엔티티(A)만 준영속 상태로 전환한다.
    • 해당 메소드가 호출된 순간 1차 캐시, 쓰기 지연 SQL 저장소 등에 존재하는 해당 엔티티 정보가 모두 제거된다.
  • em.clear(): 영속성 컨텍스트를 완전히 초기화한다.
  • em.close(): 영속성 컨텍스트를 종료한다.

준영속 상태의 특징

• 거의 비영속 상태에 가깝다.
  • 영속성 컨텍스트가 관리하지 않기 때문에, 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않는다.
• 식별자 값을 가지고 있다.
  • 영속성 상태였었기 때문에 반드시 식별자 값을 가지고 있다.
• 지연 로딩을 할 수 없다.
  • 영속성 컨텍스트가 관리하지 않기 때문에 지연 로딩 시 문제가 발생한다.

병합: merge()

• 병합을 사용하면 준영속 상태의 엔티티를 다시 영속 상태로 변경할 수 있다.
  • 준영속 상태의 엔티티를 받아서 그 정보로 새로운 영속 상태의 엔티티를 반환한다.

merge()의 동작 방식

• merge의 동작 방식은 다음과 같다.
  • merge() 실행
  • 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티 조회
    • 없으면 데이터베이스에서 조회하고 1차 캐시에 저장
  • 조회한 영속 엔티티에 입력받은 엔티티 값을 채워 넣는다.
  • 변경된 엔티티를 반환한다.