엔티티 매니저와 영속성 컨텍스트

엔티티 매니저 팩토리(entity manager factory), 엔티티 매니저(entity manager)

• 엔티티 매니저는 엔티티를 저장, 수정, 삭제, 조회하는 등 엔티티와 관련된 모든 일을 처리한다. 이름 그대로 엔티티를 관리하는 관리자이다.
• 엔티티 매니저 팩토리는 이름 그대로 엔티티 매니저를 만드는 공장인데, 엔티티 매니저 팩토리를 생성하는 비용은 매우 크다. 따라서 한 개만 생성해서 애플리케이션 전체에서 공유하도록 설계되어 있다.
• 반면, 공장에서 엔티티 매니저를 생성하는 비용은 거의 들지 않는다. 그리고 엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하므로 서로 다른 스레드 간에 공유해도 되지만, 엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드 간에 절대 공유하면 안된다. 

영속성 컨텍스트(persistence context)

• 영속성 컨텍스트는 엔티티를 영구 저장하는 환경이라는 뜻이다. 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.
• 영속성 컨텍스트는 엔티티 매니저를 생성할 때 함께 만들어진다. 그리고 엔티티 매니저를 통해서 영속성 컨텍스트에 접근할 수 있고 관리할 수 있다.
• 영속성 컨텍스트는 엔티티를 식별자 값(@Id로 테이블의 기본 키와 매핑한 값)으로 구분한다. 따라서 영속 상태는 식별자 값이 반드시 있어야 한다.

1차 캐시

영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이를 1차 캐시라고 한다. 영속 상태의 엔티티는 모두 1차 캐시에 저장된다. 1차 캐시에 데이터는 Map 형태로 저장되는데 키는 @Id로 매핑한 식별자이고, 값은 엔티티 인스턴스이다. 

 

다음 코드를 실행하면 그림처럼 1차 캐시에 회원 엔티티가 저장된다. 그리고 이 엔티티는 아직 데이터베이스에 저장되지 않는다.

Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

em.persist(member);

엔티티를 조회하는 코드는 다음과 같다. find() 메소드의 첫 번째 파라미터는 엔티티 클래스 타입이고, 두 번째는 조회할 엔티티의 식별자 값이다. em.find()를 호출하면 먼저 1차 캐시에서 엔티티를 찾고, 1차 캐시에 찾는 엔티티가 있으면 데이터베이스를 조회하지 않고 메모리에 있는 1차 캐시에서 엔티티를 조회한다.

em.find(Member.class, "member1");

만약 찾는 엔티티가 1차 캐시에 없으면 엔티티 매니저는 데이터베이스를 조회해서 엔티티를 생성한다. 그리고 1차 캐시에 저장한 후에 영속 상태의 엔티티를 반환한다.

이렇게 JPA는 엔티티를 조회할 때 1차 캐시에 있는지를 먼저 확인하고, 1차 캐시에 찾는 엔티티가 있으면 데이터베이스를 조회하지 않고 1차 캐시의 엔티티를 불러온다. 따라서 성능상 이점을 누릴 수 있다.

영속 엔티티의 동일성 보장

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
System.out.println(a == b); // 동일성 비교

위 코드에서 a == b의 동일성 비교 결과는 true이다. 영속성 컨텍스트는 1차 캐시에 있는 같은 엔티티 인스턴스를 반환하기 때문이다. 따라서 a와 b는 같은 인스턴스이다. 이렇게 영속성 컨텍스트는 엔티티의 동일성을 보장한다. 

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

엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부의 쓰기 지연 SQL 저장소에 쿼리를 모아둔다. 그리고 트랜잭션을 커밋할 때 모아둔 쿼리를 데이터베이스에 보내는데 이를 트랜잭션을 지원하는 쓰기 지연이라 한다.

 

1. em.persist()를 호출하면, 다음과 같이 1차 캐시에 엔티티가 저장되고, 만들어진 쿼리가 쓰기 지연 SQL 저장소에 보관된다.

2. 트랜잭션을 커밋하면, 커밋 전에 엔티티 매니저는 영속성 컨텍스트를 플러시한다. 따라서 쓰기 지연 SQL 저장소에 모인 쿼리가 데이터베이스에 보내진다.

 

3. 이렇게 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화한 후에 데이터베이스 트랜잭션을 커밋한다.

엔티티를 삭제하는 경우에도 마찬가지이다. em.remove(memberA)를 통해 엔티티를 삭제하면, 데이터베이스에서 엔티티가 즉시 삭제되지 않는다.

1. em.remove(memberA)를 호출하는 순간 memberA 엔티티는 영속성 컨텍스트에서 제거된다. 이렇게 삭제된 엔티티는 재사용하지 말고 자연스럽게 가비지 컬렉션의 대상이 되도록 두는 것이 좋다.
2. 삭제 쿼리가 쓰기 지연 SQL 저장소에 등록된다.
3. 이후에 트랜잭션을 커밋해서 플러시를 호출하면 쓰기 지연 SQL 저장소의 쿼리가 데이터베이스에 반영되어 데이터베이스에서 삭제되고, 데이터베이스 트랜잭션이 커밋된다.

변경 감지(dirty checking)

JPA로 데이터를 수정할 때는 단순히 엔티티를 조회해서 데이터만 변경하면 된다. 다음 코드에서 em.update() 같은 코드가 불필요하다.

Member memberA = em.find(Member.class, "memberA");

// 수정
memberA.setAge(10);

// em.update(memberA) 같은 코드 불필요

이는 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능인 변경 감지 덕분이다. JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해서 저장해두는데 이를 스냅샷이라고 한다. 그리고 플러시 시점에 스냅샷과 엔티티를 비교해서 변경된 엔티티를 찾는다.

1. 트랜잭션을 커밋하면 엔티티 매니저 내부에서 먼저 플러시가 호출된다.
2. 현재 1차 캐시에 있는 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾는다.
3. 변경된 엔티티에 대한 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보관한다.
4. 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 보낸다.
5. 데이터베이스 트랜잭션을 커밋한다.

주의할 점은 변경 감지는 영속성 컨텍스트에 의해 관리되고 있는 영속 상태의 엔티티에만 적용된다는 것이다. 그리고 JPA의 기본 전략은 엔티티 수정시 모든 필드를 업데이트한다. 예를 들어 회원 필드에 이름, 나이, 등급이 있을 때, 이름과 나이면 수정한다고 가정하자. 그러면 다음과 같은 수정 쿼리가 생성될 것이라 예상할 수 있다.

update member
set
    name=?,
    age=?
where
    id=?

그러나 다음과 같이 엔티티의 모든 필드에 대한 수정 쿼리가 생성된다.

update member
set
    name=?,
    age=?,
    grade=?
where
    id=?

이렇게 모든 필드를 업데이트하면 데이터베이스에 보내는 데이터 전송량이 증가하는 장점이 있지만, 다음 같은 장점으로 인해 모든 필드를 업데이트한다.

• 모든 필드를 업데이트하므로 수정 쿼리가 항상 같다(물론 바인딩되는 데이터는 다르다). 따라서 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용할 수 있다.
• 데이터베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 이미 한 번 파싱된 쿼리를 재사용할 수 있다.

만약 필드가 많으면 기본 전략인 정적 수정 쿼리는 성능이 떨어질 수 있다. 따라서 이 경우에는 수정된 필드만 업데이트하도록 동적 수정 쿼리를 생성하는 전략을 사용하면 된다. 다음과 같이 하이버네이트의 @DynamicUpdate를 사용하면 수정된 필드만 사용해서 동적으로 update sql이 생성된다. 

@Entity
@DynamicUpdate
@Table(name = "Member")
public class Member {}

플러시(flush)

 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 것을 말한다. 플러시를 실행하면 다음과 같은 일이 일어난다.

1. 변경 감지가 동작하여, 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교하여 수정된 엔티티를 찾는다. 
2. 수정된 엔티티에 대한 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보관한다.
3. 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 보낸다.
4. 데이터베이스 트랜잭션을 커밋한다.

플러시를 호출하는 방법은 다음과 같다.

• em.flush()를 통해 직접 호출
  • 엔티티 매니저의 flush()를 직접 호출하면, 영속성 컨텍스트를 강제로 플러시한다. 
  • 테스트나 다른 프레임워크와 JPA를 함께 사용할 때를 제외하고 거의 사용하지 않는다.
• 트랜잭션 커밋시 자동 호출
  • 트랜잭션을 커밋하면, 커밋 직전에 플러시가 호출되어 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.
• jpql 쿼리 실행시 자동 호출(ex, em.createQuery())
  • jpql 쿼리가 실행되기 직전에 플러시가 자동으로 호출된다.
  • 만약 다음 예제에서 jpql 쿼리 실행 전에 플러시가 호출되지 않으면 어떻게 될까? jpql을 실행하면 jpql은 sql로 변환되어 데이터베이스에서 데이터를 조회한다. 그런데 아직 데이터가 데이터베이스에 반영되지 않았으므로 jpql 쿼리 결과로 아무것도 조회되지 않는다. 따라서 이런 문제를 예방하기 위해 jpql 쿼리를 실행하기 직전에 플러시를 자동 호출해서 변경 내용을 데이터베이스에 반영하는 것이다.

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);

// 중간에 jpql 실행
List<Member> members = em.createQuery("select m from Member m", Member.class)
                         .getResultList();

주의할 점은 플러시를 한다고 해서 영속성 컨텍스트에 보관된 엔티티를 지우는 것은 아니라는 점이다. 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 것이지, 영속성 컨텍스트에 보관된 엔티티를 지우는 것이 아니다. 

엔티티 생명주기

엔티티에는 4가지 상태가 존재한다.

비영속(new, transient)

엔티티 객체를 생성했지만, 아직 순수한 객체 상태일 뿐 저장하지 않은 상태이다. 따라서 영속성 컨텍스트나 데이터베이스와는 전혀 관련이 없다.

Member member = new Member();

영속(managed)

엔티티 매니저를 통해 엔티티를 영속성 컨텍스트에 저장하면 엔티티는 영속성 컨텍스트에 의해 관리된다. 이렇게 영속성 컨텍스트에 의해 관리되는 상태를 영속 상태라고 한다. 

em.persist(member);

준영속(detached)

영속성 컨텍스트가 관리하던 영속 상태의 엔티티를 영속성 컨텍스트가 관리하지 않으면 준영속 상태가 된다. 따라서 준영속 상태의 엔티티는 더이상 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.

 

엔티티를 준영속 상태로 만드는 방법은 다음과 같다.

• em.detach(member): 특정 엔티티만 준영속 상태로 전환한다.
• em.clear(): 영속성 컨텍스트를 초기화해서 해당 영속성 컨텍스트가 관리하던 모든 엔티티를 준영속 상태로 만든다.
• em.close(): 영속성 컨텍스트를 종료한다. 따라서 영속성 컨텍스트가 관리하던 모든 엔티티를 준영속 상태로 만든다.

// 비영속 상태
Member member = new Member();
member.setId("memberA");
member.setUsername("회원A");

// 영속 상태
em.persist(member);

// 준영속 상태
em.detach(member);

위 코드에서 em.persist(member)를 통해 1차 캐시와 쓰기 지연 SQL 저장소에는 엔티티에 대한 정보가 등록된다.

그러나 em.detach(member)를 통해 엔티티가 준영속 상태가 되면, 1차 캐시와 쓰기 지연 SQL 저장소에서 해당 엔티티에 대한 모든 정보가 제거된다.

준영속 상태의 엔티티의 특징은 다음과 같다.

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

준영속 상태의 엔티티를 다시 영속 상태로 변경하려면 병합(merge)을 사용하면 된다. merge() 메소드는 준영속 상태의 엔티티를 받아서 그 정보로 새로운 영속 상태의 엔티티를 반환한다. 

// member: 준영속 상태
Member mergeMember = em.merge(member); // mergeMember: 영속 상태

이제 준영속 상태인 member는 사용할 필요가 없다. 따라서 다음과 같이 준영속 엔티티를 참조한던 member 변수가 영속 엔티티를 참조하도록 변경하는 것이 안전하다.

member = em.merge(member);

병합은 비영속 상태의 엔티티도 영속 상태로 만들 수 있다. 병합은 파라미터로 넘어온 엔티티의 식별자 값으로 영속성 컨텍스트를 조회하고 찾는 엔티티가 없으면 데이터베이스에서 조회한다. 만약 데이터베이스에서도 발견하지 못하면 새로운 엔티티를 생성해서 병합한다. 즉, 병합은 준영속, 비영속과 관계없이 식별자 값으로 엔티티를 찾을 수 있으면 찾아서 병합하고, 찾을 수 없으면 새로 생성해서 병합한다. 

삭제(removed)

엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제하면 삭제 상태가 된다.

em.remove(member);

---

Reference

• 자바 ORM 표준 JPA 프로그래밍, 김영한