[JPA] 영속성 컨텍스트와 엔티티

 JPA가 제공하는 기능은 크게 엔티티와 테이블을 매핑하는 설계 부분과 매핑한 엔티티를 실제 사용하는 부분으로 나눌 수 있습니다.

 

JPA를 사용하기 위해서는 먼저 EntityManager와 EntityManagerFactory에 대한 이해가 필요합니다.

---

EntityManager

매핑한 엔티티를 사용하기 위해서는 EntityManager라는 것을 사용합니다.

EntityManager는 말 그대로 Entity를 저장, 수정, 삭제, 조회 하는 등 엔티티와 관련된 모든 일들을 처리해줍니다.

+ 내부의 DataSource를 기반으로 커넥션을 얻어 DB에 접근합니다.

EntityManagerFactory

EntityManager는 EntityManagerFactory를 통해 생성할 수 있습니다.

• 엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생할 수 있기 때문에 스레드 간에 공유가 일어나면 X
• 따라서 EntityMnager는 클라이언트의 요청이 올 때 마다 EntityManagerFactory를 통해서 EntityManager 생성 

---

영속성 컨텍스트란?

영속성 컨텐스트는 엔티티를 영구 저장하는 공간으로 실제 존재하는 공간이 아닌 논리적인 개념입니다.

예를들어 EntityManager의 persist 메소드를 사용하여 member Entity를 저장하게 되면 영속성 컨텍스트에 저장됩니다.

• 영속성 컨텍스트는 EntityManager를 통해 접근할 수 있고, EntityManager를 통해 관리할 수 있습니다.

Entity의 생명주기

Entity에는 4가지 상태가 존재합니다.

엔티티 4가지 상태

1. 비영속 : 영속성 컨텍스트와 아무런 관계가 없는 순수한 객체 상태로 영속성 컨텍스트와 DB와 전혀 관련이 없는 상태입니다.

비영속

 

2. 영속 : 영속성 컨텍스트에 저장된 상태로 persist(entity)에 의해 이루어집니다. 영속 상태인 엔티티는 영속성 컨텍스트에 의해 관리됩니다.

영속

3. 준영속 : 영속성 컨텍스트에 저장되었다가 분리된 상태입니다. 특정 엔티티를 준영속 상태로 만들려면 em.detach(entity) 호출하거나 em.close()를 호출해서 영속성 컨텍스트를 닫거나, em.clear()를 호출해서 영속성 컨텍스트를 초기화하면 영속성 컨텍스트가 관리하던 엔티티는 준영속 상태가 됩니다.

 

4. 삭제 : 영속성 컨텍스트에서 삭제된 상태로 em.remove(entity)에 의해 이루어집니다.

---

영속성 컨텍스트의 특징

1. 영속성 컨텍스트가 관리하는 엔티티는 식별자 값(@Id로 테이블의 PK와 매핑한 값)으로 엔티티를 구분하기 떄문에 영속 상태의 엔티티는 반드시 식별자 값이 있어야 합니다. 식별자 값이 없으면 예외가 발생합니다.  

 

2. 영속성 컨텍스트에 보관된 엔티티(영속 상태의 엔티티)를 저장 시(em.persist()) 트랜잭션이 커밋되어야 DB에 반영됩니다.  

---

엔티티 CRUD를 통한 영속성 컨텍스트 장점 살펴보기

1. 조회 em.find() : 성능 향상 by 1차 캐시 (CRUD) 

영속성 컨텍스트는 내부에 캐시를 가지고 있습니다. 영속상태의 엔티티는 모두 캐시에 저장됩니다. (캐시는 Map<@Id, Entity>로 이루어져 있음)

EntityManager를 통해 persist 메소드로 엔티티를 저장하면 영속성 컨텍스트에 해당 엔티티가 보관됨과 동시에 1차 캐시에 해당 엔티티가 저장됩니다.

 

이 상태에서 저장한 엔티티 member를 조회하려고 할 때, JPA는 우선적으로 1차캐시에서 해당 엔티티가 있는지 조회하고, 만약 1차 캐시에 해당 엔티티가 없는 경우 DB에서 해당 엔티티를 조회합니다. DB에 우선적으로 접근하지 않고 먼저 캐시를 통해 엔티티를 조회함으로써 성능 상 이점을 얻을 수 있습니다.

 

2. 조회 em.find() : 동일성 보장 by 1차 캐시 (CRUD)

Member a = em.find(Member.class,"1L");
Member b = em.find(Member.class,"1L");

여기서 a==b는 참일까요? 거짓일까요?

답은 참입니다. 영속성 컨텍스트는 em.find()를  반복 호출해도 1차 캐시에서 해당 엔티티를 식별자 @Id를 통해 같은 인스턴스를 반환합니다. 따라서 영속성 컨텍스트는 성능상 이점과 엔티티의 동일성(같은 인스턴스임)을 보장해줍니다.

---

3. 저장 em.persist() : 트랜잭션을 지원하는 쓰기 지연 (CRUD)

• EntityManager는 트랜잭션을 커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소에 SQL을 모아둡니다.
• 트랜잭션이 커밋되는 순간 내부 쿼리 저장소에 저장된 SQL을 flush()하여 DB에 전달함으로써, 내부 쿼리 저장소에 저장된 SQL을 DB에 반영합니다.
• flush()는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 작업으로 이때 등록, 수정, 삭제 한 엔티티를 DB에 반영합니다.
• commit()은 자동으로 flush()를 호출합니다.
• 여러 쿼리를 한 번에 전달해서 커밋함으로써 성능을 최적화할 수 있습니다.

---

4. 수정 : 엔티티 변경 감지 (CRUD)

SQL을 직접 사용하면 수정 쿼리를 직접 사용해야 합니다. 만약 요구사항이 늘어나면서 속성이 추가된다면 수정 쿼리도 점점 커지게 됩니다. 하지만 JPA의 EntityManager를 사용하여 엔티티를 수정할 때는 단순히 엔티티를 조회하고 엔티티를 프로퍼티를 변경하면 됩니다.

Member member = em.find(Member.class, "1L");
member.setUsername("hi");
member.setAge(10);

뭔가 별도의 update 메소드가 있어야 할 것 같지만, 없어도 됩니다.

 

동작 과정은 이렇습니다.

• 1. JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해서 저장해둡니다. (스냅샷)
• 2. flush() 시점 (commit 시점)에 스냅샷과 엔티티를 비교해서 변경된 엔티티를 찾습니다.
• 3. 변경된 엔티티가 있으면 수정 쿼리(Update/set/where)를 생성해서 내부 쿼리 저장소에 보냅니다.
  • 이 때 기본전략은 엔티티의 모든 필드를 업데이트합니다. 
• 4. 트랜잭션을 커밋합니다.

이렇게 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능을 변경 감지라고 합니다.
* 변경 감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용

변경 감지 기능 장점

1. 모든 필드를 사용하면 수정쿼리가 같다. 따라서 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용 가능.

2. 동일한 쿼리를 데이터베이스에 보내는 경우, 데이터베이스는 이전에 한 번 파싱된 쿼리를 재사용 가능.

물론 모든 필드를 업데이트 하지 않고, org.hibernate.annotations.DynamicUpdate 를 사용해서, 동적 Update SQL을 생성할 수도 있습니다.

---

5. 삭제 : em.remove() 

엔티티를 삭제하려면 삭제 대상 엔티티를 조회해야 합니다.

Member member = em.find(Member.class, "1L");
em.remove(member);

물론 마찬가지로 commit() 을 호출해야 실제 데이터 베이스에 삭제 쿼리를 전달합니다.

• 이 때 참고로 remove를 호출하는 순간 member는 영속성 컨텍스트에서 제거됩니다.
• rollback시에는 영속성 컨텍스트에 해당 엔티티 복구됨.

---

플러시 

플러시(flush())는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영합니다.

 

플러시를 실행하면 다음 동작을 수행합니다.

1. 변경 감지가 동작해서, 모든 엔티티를 스냅샷을 비교해서 수정된 엔티티를 찾음.

 

2. 수정된 엔티티는 수정쿼리를 만들어 영속성 컨텍스트 내부 SQL 저장소에 보관.

 

3. 내부 SQL 저장소에 등록된 쿼리를 데이터베이스에 전송(등록, 수정, 삭제 쿼리)

 

영속성 컨텍스트의 플러시를 호출하는 방법에는

• em.flsuh()로 직접 호출하는 방법
• commit()을 통해 플러시를 자동호출 하는 방법
• JPQL 쿼리 실행을 통해 플러시를 자동으로 호출하는 방법 

총 세 가지 방법이 있습니다.

 

직접 em.flush()를 호출함으로써 플러시하는 방법은 잘 사용하지 않고, 보통 commit()을 통해 플러시를 자동호출하는 방법을 사용합니다.

 

JPQL 쿼리를 실행하면 왜 자동으로 flush()를 호출할까요?

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

// 중간에 JPQL 쿼리 실행 
query = em.createQuery("select m from Member m", Member.class);
List<Member> list = query.getResultList();

1. 먼저 persist를 통해 memberA, memberB, memberC를 영속상태로 만들었습니다.

2. 이때 JPQL을 실행하면 JPQL은 SQL로 변환되어 데이터베이스에서 엔티티를 조회합니다.

3. 하지만 memberA, memberB, memberC는 아직 데이터베이스에 반영된 상태가 아니기 때문에 쿼리 결과로 조회되지 않습니다.

4. 따라서 쿼리를 실행하기 직전에 영속성 컨텍스트를 flush()해서 변경 내용을 데이터베이스에 반영해야 하는데 JPA는 이런 문제를  예방하기 위해서 JPQL을 실행할 때도 플러시를 자동으로 호출합니다.

 

주의 : 한 트랜잭션 내에서 find() 메소드는 실행 직전 flush()를 실행하지 않습니다. 따라서 한 트랜잭션 내에서 find 로는 조회불가

플러시 모드 옵션 

엔티티 매니저에 플러시 모드를 직접 지정하려면 javax.persistence.FlushModeType을 사용하면 됩니다.

 

FlushModeType.AUTO : 커밋이나 쿼리(JPQL,SQL)를 실행할 때 플러시 (Default)

FlushModeType.COMMIT : 커밋할 때만 플러시

COMMIT은 성능 최적화를 위해 사용.

---

준영속 상태 (영속 ➡️ 준영속)

영속성 컨텍스트가 관리하는 영속 상태의 엔티티가, 영속성 컨텍스트에서 분리된 것을 준영속 상태라고 합니다.

• 준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없습니다.

영속상태의 엔티티를 준영속 상태로 바꾸는 방법

• 1. em.detach(entity) : 특정 엔티티만 준영속 상태로 전환 
  • entity는 영속성 컨텍스트 내 entity 관련된 1차 캐시 및  내부 SQL 쿼리 저장소에서 삭제되고 해당 entity는 준영속 상태가 됩니다.

• 2. em.clear() : 영속성 컨텍스트를 완전히 초기화
  • 영속성 컨텍스트 내의 1차캐시와 내부 SQL 쿼리 저장소가 초기화되고 저장되어 있던 entity들은 준영속 상태가 됩니다.
• 3. em.close() : 영속성 컨텍스트를 종료
  • 영속성 컨텍스트 내의 1차캐시와 내부 SQL 쿼리 저장소가 초기화되고 저장되어 있던 entity들은 준영속 상태가 됩니다.
  • 추가적으로 영속성 컨텍스트를 종료

준영속 상태 특징

1. 영속성 컨텍스트가 관리하지 않으므로 거의 비영속 상태에 가깝습니다.

2. 비영속 상태와 달리 식별자 값을 가지고 있습니다. (영속 상태일 때 가지고 있던 식별자를 그대로 가지고 있음)

3. 지연로딩 불가 : 준영속 상태에서느 실제 객체대신 프록시 객체를 로딩해두고 해당 객체를 실제 사용할 때 영속성 컨텍스트를 통해 데이터를 불러오는 방법인 지연로딩이 불가능합니다.

 

그렇다면 준영속 상태의 엔티티를 영속 상태로 다시 변경하려면 어떻게 해야 할까요?

---

준영속 상태 (준영속 ➡️ 영속)

병합을 사용하면 됩니다. ( em.merge() )

merge() 메소드는 준영속 상태의 엔티티를 받아서 그 정보로 새로운 영속 상태의 엔티티를 반환합니다.

 

TestCode

public class MergeMain_115 {
    public static void main(String[] args) {
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");

        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        Member member = new Member();

        // 1. member 객체 생성 및 저장 -> 커밋함으로써 DB에 수정사항 반영
        try {
            member.setId(6301L);
            member.setName("김동웅");
            em.persist(member);
            tx.commit();
        } catch (Exception e) {
            tx.rollback();
        } finally {
            // 1.1 member 준영속 상태로 변경
            em.close();
        }

        // 2. 준영속 상태로 변경되었으므로 수정사항 DB에 반영 X
        member.setName("김동웅2");

        EntityManager em2 = emf.createEntityManager();
        EntityTransaction tx2 = em2.getTransaction();
        tx2.begin();

        // 3. 준영속 상태의 member 객체 -> 영속상태로 변경 
        try {
            // merge()하여 영속상태로 변경
            Member mergeMember = em2.merge(member);
            tx2.commit();

            // 준영속 상태의 member
            System.out.println("member = " + member);
            // merge로 인해 영속상태로 바뀐 member
            System.out.println("mergeMember = " + mergeMember);

        } catch (Exception e) {
            tx2.rollback();
        } finally {
            em2.close();
        }
    }
}

1.  member 객체를 생성하고 persist로 저장하여 영속상태로 만든 후 commit함으로 쓰기 지연 SQL 쿼리를 DB에 전달하여 데이터를 DB에 반영했습니다.

 

2. 1에서 영속성 컨텍스트를 닫음으로써 준영속 상태로 바뀐 member는 프로퍼티를 변경해도 DB에 반영되지 않습니다.

 

3.. 영속성 컨텍스트를 닫으면서 준영속 상태로 바뀐 member 객체를 다시 영속 상태로 변경하기 위해 merge() 메소드를 사용했습니다.

em.merge(member) 동작 방식

▶︎ em.merge(member) 실행

▶︎ 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티 조회 ( 1차 캐시에 해당 엔티티 없으면 DB에서 조회하고 1차 캐시에 저장)

▶︎ 조회한 영속 엔티티에 member 엔티티의 값을 채워 넣습니다. ( member 엔티티의 모든 프로퍼티를 새로운 엔티티(mergeMember에 주입 )

▶︎ mergeMember 리턴 

 

merge() 메소드는 준영속 뿐만 아니라 비영속상태의 엔티티도 영속 상태로 변경해줍니다. 
식별자 값으로 엔티티를 조회할 수 있으면 불러서 병합하고, 없으면, 새로 생성해서 병합합니다. 

---

<정리>

• EntityManager는 EntityManagerFactory에서 생성합니다.
• 영속성 컨텍스트는 Application과 DB사이에서 객체를 보관하는 가상의 데이터베이스같은 역할로, 실제 존재하는 것이 아니라 App과 DB사이에서의 Entity의 상태를 쉽게 이해하기 위해 도입한 개념입니다.
• 영속성 컨텍스트에 저장한 엔티티는 flush() 시점에 컨텍스트 내부의 SQL 저장소가 DB에 전달되면서 수정, 삭제, 조회, 생성의 쿼리가 데이터베이스에 반영됩니다. 트랜잭션 커밋시점에 영속성 컨텍스트가 flush() 됩니다.
• 영속성 컨텍스트 내부에 존재하는 엔티티는 영속 상태의 엔티티로 컨텍스트가 제공하는 쓰기 지연, 변경 감지, 지연 로딩, 1차 캐시, 동일성 보장 같은 기능 사용 가능
• 준영속(detach), 비영속(remove) 상태의 엔티티는 컨텍스트가 제공하는 기능을 사용할 수 없습니다.

---

<참고자료>

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