Chapter 03. 영속성 관리
JPA가 제공하는 기능은 크게 엔터티와 테이블을 매핑하는 설계 부분, 매핑한 엔터티를 실제 사용하는 부분으로 나눌 수 있다. 이 장에서는 엔터티 매니저(EntityManager)를 통해 엔터티를 어떻게 사용하는지 알아본다.
엔터티 매니저를 엔터티에 대해 CRUD 작업을 수행하는 등 엔터티와 관련된 모든 일을 처리한다. 개발자 입장에서 엔터티 매니저는 엔터티를 저장하는 가상의 데이터베이스로 이해할 수 있다.
3.1 엔터티 매니저 팩토리와 엔터티 매니저
// 공장 만들기, 비용이 아주 많이 든다.
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("jpabook");데이터베이스를 하나만 사용하는 애플리케이션은 일반적으로 위와 같이 EntityManagerFactory를 하나만 생성한다. Persistence.createEntityManagerFactory("jpabook")을 호출하면 resources/META-INF/persistence.xml에 명시된 정보 중 영속성 유닛(persistence-unit)의 이름이 jpabook인 것의 설정을 바탕으로 EntityManagerFactory를 생성한다.
예제 3.1. persistence.xml 코드
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" version="2.2"> <persistence-unit name="jpabook">
<properties>
<property name="jakarta.persistence.jdbc.driver" value="org.h2.Driver"/>
<property name="jakarta.persistence.jdbc.user" value="sa"/>
<property name="jakarta.persistence.jdbc.password" value=""/>
<property name="jakarta.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>
<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect" />
<property name="hibernate.show_sql" value="true" />
<property name="hibernate.format_sql" value="true" />
<property name="hibernate.use_sql_comments" value="true" />
<property name="hibernate.id.new_generator_mappings" value="true" />
</properties>
</persistence-unit>
</persistence>이제부터 필요할 때마다 다음과 같이 엔터티 매니저 팩토리에서 엔터티 매니저를 생성하면 된다.
// 공장에서 엔터티 매니저 생성, 비용이 거의 안 든다.
EntityManager em = emf.createEntityManager();엔터티 매니저 팩토리와 엔터티 매니저의 차이는 다음과 같다.
- 엔터티 매니저 팩토리
- 생성 비용이 상당히 크다.
- 스레드 안전(thread-safe)하다.
- 엔터티 매니저
- 생성 비용이 거의 없다.
- 스레드 비안전(thread-unsafe)하다.
하나의 EntityManagerFactory 객체로부터 여러 개의 EntityManager 객체가 생성된다. 생성된 EntityManager 객체는 데이터베이스 연결이 필요한 시점까지 커넥션을 얻는 행위를 지연한다. 보통 커넥션을 얻는 시점은 트랜잭션을 시작할 때이다.
J2SE 환경에서 하이버네이트를 포함한 JPA 구현체들은 EntityManagerFactory를 생성할 때 커넥션 풀도 생성하고, 스프링 프레임워크를 포함한 J2EE 환경에서는 해당 컨테이너가 제공하는 데이터 소스를 사용한다.
3.2 영속성 컨텍스트란?
영속성 컨텍스트(persistence context)란 엔터티를 영구 저장하는 환경을 의미한다. 엔터티 매니저로 엔터티를 관리하면 엔터티 객체들은 영속성 컨텍스트에 보관되고 관리된다. 그러므로 persist() 메서드도 엄밀히 말하자면 엔터티 매니저를 사용해 회원 엔터티를 영속성 컨텍스트에 저장하는 행위를 의미한다.
영속성 컨텍스트는 엔터티 매니저를 생성할 때 하나 만들어지며, 엔터티 매니저를 통해 접근할 수 있다. 또한 서로 다른 엔터티 매니저 간 같은 영속성 컨텍스트에 접근할 수도 있다.
3.3 엔터티의 생명주기
엔터티에는 4가지 상태가 존재한다.
- 비영속(new/transient): 영속성 컨텍스트와 전혀 관계가 없는 상태
- 영속(managed): 영속성 컨텍스트에 저장된 상태
- 준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태
- 삭제(removed): 삭제된 상태
비영속
// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");위와 같이 엔터티 객체를 생성한 직후엔 순수한 객체 상태이며, 영속성 컨텍스트나 데이터베이스와는 어떤 관련도 없는 비영속 상태이다.
영속
// 객체를 저장한 상태(영속)
em.persist(member);위와 같이 엔터티 매니저의 persist() 메서드를 사용해 엔터티를 영속성 컨텍스트에 저장할 수 있다. 이렇게 영속성 컨텍스트가 관리하는 영속 상태의 엔터티가 된다. 결국 영속 상태란 영속성 컨텍스트에 의해 관리되는 상태를 의미한다. 또한, em.find() 메서드나 JPQL을 통해 조회한 엔터티도 영속성 컨텍스트의 관리 하에 놓이게 된다.
준영속
// 회원 엔터티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);위와 같이 엔터티 매니저의 em.detach() 메서드를 호출해 특정 엔터티를 준영속 상태로 만들 수 있다. 이외에도 em.close() 메서드로 영속성 컨텍스트를 닫거나 em.clear() 메서드로 영속성 컨텍스트를 초기화하면 영속성 컨텍스트에 포함된 모든 엔터티 객체들이 준영속 상태가 된다.
삭제
// 객체를 삭제한 상태(삭제)
em.remove(member);위와 같이 엔터티 매니저의 remove() 메서드를 호출하면 엔터티를 영속성 컨텍스트와 데이터베이스에서 삭제한다.
3.4 영속성 컨텍스트의 특징
영속성 컨텍스트의 특징은 다음과 같다.
영속성 컨텍스트와 식별자 값
영속성 컨텍스트는 엔터티를 식별자 값(@Id 애너테이션으로 지정한 필드의 값)으로 구분한다. 따라서 영속 상태의 엔터티 객체는 식별자 값을 갖고 있어야 한다. 식별자 값이 없으면 예외가 발생한다.
영속성 컨텍스트와 데이터베이스 저장
JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트의 변경 사항을 데이터베이스에 반영한다(플러시, flush).
영속성 컨텍스트가 엔터티 객체를 관리할 시의 장점
- 1차 캐시: 찾고자 하는 엔터티 객체가 이미 영속성 컨텍스트에 있다면 데이터베이스 작업을 수행하지 않고 객체를 즉시 반환한다. 이에 따라 데이터베이스의 트랜잭션 격리 수준이 REPEATABLE READ 미만이더라도 그에 준하는 트랜잭션 격리성을 가질 수 있다.
- 동일성 보장: 1차 캐시로 덕분에 같은 엔터티 객체를 요구하면 영속성 컨텍스트에 유일하게 존재하는 객체가 매번 반환되어 같은 주소 값을 갖는다.
- 트랜잭션을 지원하는 쓰기 지연: 트랜잭션 안에서 엔터티 객체를 수정하면 이를 즉시 데이터베이스에 반영하지 않고 영속성 컨텍스트에서 트랜잭션이 끝날 때까지 관리한다. 이에 따라 매번 변경 사항을 데이터베이스에 반영하지 않고 JDBC 배치 기능을 활용해 한 번에 커밋함으로써 성능을 최적화할 수 있다.
- 변경 감지: 엔터티 객체가 변경되면 영속성 컨텍스트에서 감지할 수 있다. 이를 통해 트랜잭션을 커밋할 때 트랜잭션 시작 시점의 스냅샷과 대조하여 변경된 사항만을 반영하는
UPDATE쿼리를 생성할 수 있다. - 지연 로딩: 엔터티 객체가 영속성 컨텍스트에 생성될 때 지연 로딩이 설정된 객체 필드에 JPA가 생성한 프록시 객체가 주입된다. 이에 따라 연관된 객체가 필요한 시점까지 영속성 컨텍스트에 해당 객체의 로딩을 지연할 수 있다.
3.4.1 엔터티 조회
영속성 컨텍스트는 내부에 1차 캐시라고 불리는 캐시를 가지고 있으며, 영속 상태의 엔터티 객체는 모두 이곳에 저장된다. 추상화하여 영속성 컨텍스트 내부에 Map<[@Id annotated field's type], [Object type]> 컬렉션이 하나 존재한다고 생각할 수 있다.
// 엔터티를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
// 엔터티 영속
em.persist(member);위 코드를 실행하면 다음과 같이 영속성 컨텍스트의 1차 캐시에 회원 엔터티를 저장한다. 이때 회원 엔터티는 데이터베이스에 아직 저장되지 않은 상태이다.
영속성 컨텍스트에서 데이터를 식별하기 위한 기준은 데이터베이스의 기본 키 값이다.
엔터티 매니저의 find() 메서드는 <T> T find(Class<T> var1, Object var2);와 같이 정의되어 있다. 첫 번째 매개변수는 찾고자 하는 엔터티의 클래스, 두 번째 매개변수는 @Id로 애너테이션된 필드의 값이다. 호출 시 1차 캐시에서 우선 엔터티를 찾고 존재하지 않는다면 데이터베이스로부터 조회한다.
1차 캐시에서 조회
엔터티 조회 시 우선 1차 캐시에서 식별자 값으로 엔터티를 찾는다. 엔터티가 존재한다면 해당 엔터티 객체는 데이터베이스가 아닌 메모리로부터 반환된다.
데이터베이스 조회
엔터티 조회 시 1차 캐시에 부재한다면 엔터티 매니저는 먼저 데이터베이스로부터 엔터티를 조회해 영속성 컨텍스트의 1차 캐시에 엔터티 객체를 생성한다. 그리고 이렇게 1차 캐시에 저장된 영속 상태의 엔터티 객체를 사용자에게 반환한다.
영속 엔터티의 동일성 보장
Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
System.out.println(a == b); // 동일성 비교위와 같이 엔터티 매니저의 find() 메서드를 통해 반복적으로 같은 엔터티를 요구하면 엔터티 매니저는 영속성 컨텍스트의 1차 캐시에 있는 동일한 인스턴스를 반환한다. 따라서 영속성 컨텍스트는 성능상의 이점과 엔터티의 동일성을 보장한다. 또한, 트랜잭션의 REPEATABLE READ 격리 수준을 애플리케이션 레벨에서 제공할 수 있다.
3.4.2 엔터티 등록
예제 3.2. 엔터티 등록 코드
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
// 엔터티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다.
transaction.begin(); // [트랜잭션] 시작
em.persist(memberA);
em.persist(memberB);
// 여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.
// 커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋위와 같은 코드가 실행될 때 엔터티 매니저는 트랜잭션 커밋 전까지 엔터티를 데이터베이스에 저장하지 않고 INSERT SQL을 모아두었다가 트랜잭션 커밋 시 모아두었던 SQL을 데이터베이스로 한 번에 전송한다. 이를 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)이라고 한다.
memberA 엔터티를 영속화하면 엔터티 매니저는 영속성 컨텍스트의 1차 캐시에 회원 엔터티를 저장하는 동시에 회원 엔터티의 정보를 기반으로 INSERT 쿼리를 생성해 쓰기 지연 SQL 저장소에 보관한다.
memberB 엔터티를 영속화하면 엔터티 매니저는 기존과 같은 방식으로 1차 캐시와 쓰기 지연 SQL 저장소에 정보를 누적한다. 핵심은 아직까지 데이터베이스로 어떤 쿼리도 전송되지 않았다는 것이다.
트랜잭션을 커밋할 때에서야 비로소 엔터티 매니저는 먼저 쓰기 지연 SQL 저장소에 모인 쿼리를 한 번에 데이터베이스로 플러시하고 트랜잭션을 커밋한다.
트랜잭션을 지원하는 쓰기 지연이 가능한 이유
begin(); // 트랜잭션 시작
save(A);
save(B);
save(C);
commit(); // 트랜잭션 커밋위 로직을 다음과 같은 2가지 경우로 생각해 보자.
- 데이터를 저장하는 즉시
INSERT쿼리를 데이터베이스로 전송한다. - 데이터를 저장할 시
INSERT쿼리를 버퍼링하고 트랜잭션 커밋 시 한 번에 데이터베이스로 전송한다.
트랜잭션의 원자성 때문에 어차피 데이터베이스 레벨에서는 쿼리를 미리 전송하더라도 물리적인 디스크에 I/O가 발생하지 않고 언두 로그 등에 보관될 것이다. 그러므로 애플리케이션 레벨에서는 쿼리를 버퍼링해두고 트랜잭션 커밋 전에만 전송하면 데이터베이스의 동작은 동일하게 된다. 이것이 트랜잭션을 지원하는 쓰기 지연이 가능한 이유이다.
3.4.3 엔터티 수정
SQL 수정 쿼리의 문제점
보통 수정 쿼리에 수정해야 할 컬럼이 추가되면 기존의 쿼리를 수정하지 않고 새로운 쿼리를 추가하는 식으로 개발한다. 이러면 수정 쿼리가 늘어나는 것은 물론이거니와 비즈니스 로직을 분석하기 위해 SQL을 계속 확인해야 한다. 따라서 직접적/간접적으로 비즈니스 로직이 SQL에 의존하게 된다.
변경 감지
예제 3.3. 엔터티 수정
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // [트랜잭션] 시작
// 영속 엔터티 조회
Member memberA = em.find(Member.class, "memberA");
memberA.setUsername("hi");
memberA.setAge(10);
transaction.commit(); // [트랜잭션] 커밋JPA는 엔터티의 변경 사항을 데이터베이스에 자동으로 반영하는 변경 감지(dirty checking)라는 기능을 제공하기 때문에 update()와 같은 메서드를 제공하지 않아도 엔터티의 수정 사항을 데이터베이스에 반영할 수 있다.
JPA는 엔터티를 최초로 영속성 컨텍스트에 추가할 때 스냅샷을 생성한다. 그리고 플러시 시점에 스냅샷과 엔터티를 비교하여 변경된 엔터티를 찾는다. 구체적인 과정은 다음과 같다.
- 트랜잭션 커밋 시 엔터티 매니저 내부에서 먼저 플러시(
flush())가 호출된다. - 엔터티와 스냅샷을 비교해 변경된 엔터티를 찾는다.
- 변경된 엔터티가 있으면 수정 쿼리를 생성해 쓰기 지연 SQL 저장소에 저장한다.
- 쓰기 지연 저장소의 SQL을 데이터베이스에 전송한다.
- 데이터베이스 트랜잭션을 커밋한다.
변경 감지는 영속성 컨텍스트에서 관리되는 영속 상태의 엔터티에만 적용된다.
위 예제처럼 회원의 이름과 나이만 수정하는 경우 다음과 같이 동적으로 수정 쿼리가 생성될 것이라 예상할 수 있다.
예제 3.4. 수정된 데이터만 반영할 것으로 예상
UPDATE MEMBER
SET
NAME=?,
AGE=?
WHERE
id=?하지만 JPA의 기본 전략은 엔터티의 모든 필드를 업데이트하는 것이다.
예제 3.5. 실제는 엔터티의 모든 필드를 수정에 반영
UPDATE MEMBER
SET
NAME=?,
AGE=?,
GRADE=?,
...
WHERE
id=?이렇게 모든 필드를 수정하면 데이터베이스에 보내는 데이터 전송량이 증가한다는 단점이 있지만, 기본적으로 다음과 같은 장점이 더 크다고 판단한다.
- 모든 필드를 사용하면 수정 쿼리의 포맷은 항상 같다. 따라서 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해 두고 재사용할 수 있다.
- 데이터베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 한 번 파싱된 쿼리를 재사용할 수 있다.
그런데 만약 단점이 더 큰 것으로 확인되는 상황이라면 엔터티 클래스를 @org.hibernate.annotations.DynamicUpdate 애너테이션으로 지정하여 수정된 필드만으로 구성된 동적인 UPDATE 쿼리를 생성할 수 있다. 이와 유사하게 @org.hibernate.annotations.DynamicInsert 애너테이션으로 지정하면 삽입될 필드만으로 구성된 동적인 INSERT 쿼리를 생성할 수 있다. 일반적으로 테이블의 컬럼이 30개 이상일 경우 이러한 방식이 더 빠르다고 한다.
3.4.4 엔터티 삭제
Member memberA = em.find(Member.class, "memberA");
em.remove(memberA);엔터티를 삭제하려면 먼저 대상 엔터티를 조회해야 한다. 엔터티 삭제 역시 트랜잭션 안에서는 쓰기 지연 SQL 저장소에 쿼리를 버퍼링하도록 설계되어 있다. 하지만 remove() 메서드 호출 즉시 해당 엔터티는 영속성 컨텍스트에서 삭제되어 삭제 상태가 된다. 이렇게 삭제된 엔터티는 재사용하지 않고 자연스럽게 가비지 컬렉션의 대상이 되도록 두는 것이 좋다.
3.5 플러시
플러시(flush())는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다. 플러시를 실행하면 다음과 같은 과정이 발생한다.
- 변경 감지 메커니즘으로 영속성 컨텍스트에 있는 모든 엔터티를 스냅샷과 비교하는 과정이 일어난다. 이때 수정된 엔터티에 대한 수정 쿼리가 생성되어 쓰기 지연 SQL 저장소에 버퍼링된다.
- 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.
영속성 컨텍스트를 플러시하는 방법은 3가지가 있다.
flush()메서드 직접 호출- 트랜잭션 커밋
- JPQL 쿼리 실행
직접 호출
엔터티 매니저의 flush() 메서드를 직접 호출하면 강제로 플러시된다. 테스트 또는 다른 프레임워크와 JPA를 함께 사용할 때를 제외하고 거의 사용되지 않는다.
트랜잭션 커밋 시 플러시 자동 호출
트랜잭션 커밋 시 플러시를 수행하지 않으면 변경 사항이 데이터베이스에 기록되지 않기 때문에 JPA는 트랜잭션 커밋 시 플러시를 자동으로 호출하도록 기본 동작을 설계했다.
JPQL 쿼리 실행 시 플러시 자동 호출
예제 3.6. JPQL 쿼리 실행 코드
em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
// 중간에 JPQL 실행
TypedQuery<Member> query = em.createQuery("SELECT m FROM Member m", Member.class);
List<Member> members = query.getResultList();JPQL은 SQL로 변환되어 데이터베이스로부터 엔터티를 조회한다. 하지만 트랜잭션 내에서 영속 상태가 된 memberA, memberB, memberC는 데이터베이스에는 아직 저장되지 않은 상태이다. 이때의 불일치를 해결하기 위해 JPQL을 실행하기 직전에 플러시를 자동 호출해 현재 트랜잭션의 변경 내용을 데이터베이스에 즉시 반영한다. 하지만 JPQL이 아닌 find() 메서드를 통한 조회는 영속성 컨텍스트로부터 조회하기 때문에 플러시를 호출하지 않는다.
3.5.1 플러시 모드 옵션
엔터티 매니저에 플러시 모드를 직접 지정하려면 jakarta.persistence.FlushModeType을 사용하면 된다.
FlushModeType.AUTO: 커밋이나 쿼리를 실행할 때 플러시(기본 값)FlushModeType.COMMIT: 커밋할 때만 플러시
em.setFlushMode(FlushModeType.COMMIT);과 같이 플러시 모드를 직접 설정할 수 있다.
3.6 준영속
준영속 상태는 영속성 컨텍스트에서 관리되던 엔터티가 분리된(detached) 상태를 의미한다. 따라서 준영속 상태의 엔터티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
영속 상태의 엔터티를 준영속 상태로 만드는 방법은 크게 3가지이다.
em.detach(entity): 특정 엔터티를 준영속 상태로 전환em.clear(): 영속성 컨텍스트 초기화em.close(): 영속성 컨텍스트 종료
3.6.1 엔터티를 준영속 상태로 전환: detach()
예제 3.7. detach() 메서드 정의
void detach(Object var1);detach() 메서드의 정의는 위와 같다.
예제 3.8. detach() 테스트 코드
public void testDetached() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
try {
transaction.begin();
// 회원 엔터티 생성, 비영속 상태
Member member = new Member();
member.setId("memberA");
member.setUsername("회원A");
member.setAge(10);
// 회원 엔터티 영속 상태
em.persist(member);
// 회원 엔터티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);
transaction.commit();
} catch (Exception e) {
transaction.rollback();
}
}먼저 회원 엔터티를 생성하고 영속화한 다음 detach() 메서드를 호출했다. 엔터티가 준영속 상태가 되는 순간 영속성 컨텍스트의 1차 캐시 및 쓰기 지연 SQL 저장소까지 엔터티를 관리하기 위한 모든 정보가 제거된다.
영속 상태가 영속성 컨텍스트에 관리(managed)되는 상태라면 준영속 상태는 영속성 컨텍스트로부터 분리(detached)된 상태이다. 이처럼 엔터티 상태에 대한 용어들은 모두 영속성 컨텍스트 기준으로 정의되어 있다.
3.6.2 영속성 컨텍스트 초기화: clear()
clear() 메서드는 영속성 컨텍스트를 초기화함으로써 영속성 컨텍스트의 모든 엔터티를 준영속 상태로 만든다.
예제 3.9. 영속성 컨텍스트 초기화
// 엔터티 조회, 영속 상태
Member member = em.find(Member.class, "memberA");
// 영속성 컨텍스트 초기화
em.clear();
// 준영속 상태
member.setUsername("changedName");
영속성 컨텍스트가 종료된 이후엔 변경 감지도 동작하지 않기 때문에 회원의 이름을 변경해도 데이터베이스에는 반영되지 않는다.
3.6.3 영속성 컨텍스트 종료: close()
close() 메서드로 영속성 컨텍스트를 종료함으로써 영속성 컨텍스트의 모든 엔터티를 준영속 상태로 만든다.
예제 3.10. 영속성 컨텍스트 닫기
public void closeEntityManager() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // [트랜잭션] - 시작
Member memberA = em.find(Member.class, "memberA");
Member memberB = em.find(Member.class, "memberB");
transaction.commit(); // [트랜잭션] - 커밋
em.close(); // 영속성 컨텍스트 닫기(종료)
}
영속 상태의 엔터티는 주로 영속성 컨텍스트가 종료되면서 준영속 상태가 되고, 개발자가 직접 준영속 상태로 만드는 일은 드물다.
3.6.4 준영속 상태의 특징
거의 비영속 상태에 가깝다
영속성 컨텍스트에서 관리되지 않으므로 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩 등 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않는다.
식별자 값을 가지고 있다
비영속 상태는 식별자 값이 없을 수도 있으나 준영속 상태는 이미 한 번 영속 상태였기 때문에 반드시 식별자 값을 가지고 있다.
지연 로딩을 할 수 없다
지연 로딩(lazy loading)은 실제 객체 대신 프록시 객체를 로딩해 두고 필요할 때 영속성 컨텍스트를 통해 불러오는 기능이다. 하지만 영속성 컨텍스트가 제공하는 기능을 사용할 수 없으므로 지연 로딩 시 문제가 발생한다.
3.6.5 병합: merge()
merge() 메서드로 준영속 상태의 엔터티를 다시 영속 상태로 변경할 수 있다. 이 메서드는 새로운 영속 상태의 엔터티를 반환한다.
예제 3.11. merge() 메서드 정의
<T> T merge(T var1);예제 3.12. merge() 사용 예
Member mergedMember = em.merge(member);준영속 병합
예제 3.13. 준영속 병합 예제
@SpringBootTest
public class MergeTest {
static EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");
@Test
public void testMerge() {
Member member = createMember("yush1nk1m", "유신", 25);
member.setUsername("changedMember");
mergeMember(member);
}
Member createMember(String id, String username, int age) {
// 영속성 컨텍스트 1 시작
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();
Member member = new Member();
member.setId(id);
member.setUsername(username);
member.setAge(age);
em.persist(member);
tx.commit();
// 영속성 컨텍스트 1 종료
em.close();
return member;
}
void mergeMember(Member member) {
// 영속성 컨텍스트 2 시작
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();
Member mergedMember = em.merge(member);
tx.commit();
// 준영속 상태
System.out.println("member = " + member.getUsername());
// 영속 상태
System.out.println("merged Member = " + mergedMember.getUsername());
System.out.println("em.contains(member) = " + em.contains(member));
System.out.println("em.contains(mergedMember) = " + em.contains(mergedMember));
// 영속성 컨텍스트 2 종료
em.close();
}
@AfterAll
public static void afterAll() {
EntityManager em = emf.createEntityManager();
Member member = em.find(Member.class, "yush1nk1m");
em.remove(member);
emf.close();
}
}출력 결과는 다음과 같다.
member = changedMember
merged Member = changedMember
em.contains(member) = false
em.contains(mergedMember) = truemember엔터티는createMember()메서드의 영속성 컨텍스트에서 영속 상태였다가 준영속 상태로 전환되고 반환된다.testMerge()메서드에서 회원 이름을 변경했지만 이는 변경 감지되지 않는다.mergeMember()메서드에서merge()메서드로 영속 상태로 전환되면서 변경 감지 메커니즘이 작동하여 데이터베이스에 반영된다.
위 그림에 나타난 merge() 메서드의 동작 방식은 다음과 같다.
merge()를 실행한다.- 매개변수로 전달된 준영속 상태 엔터티의 식별자 값으로 1차 캐시에서 엔터티를 조회한다.
2-1. 1차 캐시에 엔터티가 없으면 데이터베이스에서 엔터티를 조회하고 1차 캐시에 저장한다. - 조회한 영속 엔터티(
mergedMember)에member엔터티의 모든 필드 값을 채워 넣는다. mergedMember를 반환한다.
예제 코드에서 contains() 메서드로 member, mergedMember는 서로 다른 인스턴스임을 확인할 수 있다. 즉, member 인스턴스 자체는 다시 영속성 컨텍스트에 등록할 수 없다. 그래서 member = em.merge(member);와 같이 코드를 작성하는 것이 안전하다.
비영속 병합
Member member = new Member();
Member newMember = em.merge(member); // 비영속 병합위와 같이 비영속 상태의 엔터티 역시 병합하여 영속 상태로 만들 수 있다. 병합은 매개변수로 넘어온 엔터티의 식별자 값으로 영속성 컨텍스트를 조회하고, 찾는 엔터티가 부재하면 데이터베이스로부터 조회한다. 만약 데이터베이스에도 부재하다면 새로운 엔터티를 생성해 병합한다.
병합은 준영속, 비영속을 구분하지 않는다. 식별자 값으로 엔터티를 조회할 수 있으면 조회 후 병합하고, 조회할 수 없으면 새롭게 생성해 병합한다. 즉, 병합은 save or update 기능을 수행한다.
3.7 정리
- 엔터티 매니저는 엔터티 매니저 팩토리에서 생성한다. 자바를 직접 다루는 J2SE 환경에서는 엔터티 매니저를 만들면 그 내부에 영속성 컨텍스트도 함께 만들어진다. 이 영속성 컨텍스트는 엔터티 매니저를 통해 접근할 수 있다.
- 영속성 컨텍스트는 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. 영속성 컨텍스트 덕분에 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 기능을 사용할 수 있다.
- 영속성 컨텍스트에 저장한 엔터티는 플러시 시점에 데이터베이스에 반영되는데 일반적으로 트랜잭션 커밋 시 영속성 컨텍스트가 플러시된다.
- 영속성 컨텍스트에서 관리되는 엔터티는 영속 상태, 더 이상 관리되지 않는 상태를 준영속 상태의 엔터티라고 한다. 준영속 상태의 엔터티는 영속성 컨텍스트가 제공하는 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 등의 기능을 사용할 수 없다.
