[SPRING]자바 ORM 표준 JPA 프로그래밍 섹션3 (영속성 관리 - 내부 동작 방식)

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

1. 엔티티 매니저 팩토리(Entity Manager Factory):
   • 이는 애플리케이션 전반에 걸쳐 오직 한 번만 생성되며, 클라이언트의 요청이 있을 때마다 새로운 엔티티 매니저 인스턴스를 생성하는 공장 역할을 한다. 엔티티 매니저 팩토리는 데이터베이스 세션을 시작하는 데 필요한 설정 정보(예: 데이터베이스 연결 정보, Dialect 등)를 관리한다.
2. 엔티티 매니저(Entity Manager):
   • 엔티티 매니저는 엔티티 매니저 팩토리에 의해 생성되며, 실제로 엔티티와 관련된 작업들을 수행한다. 엔티티를 저장, 수정, 삭제, 조회하는 기능을 담당하며 각 클라이언트 요청 별로 생성되어 요청이 끝나면 폐기된다. 이는 데이터베이스 트랜잭션과 직접적으로 관련이 있으며, 엔티티의 생명주기를 관리한다.

 

💡영속성 컨텍스트

 

💻 영속성 컨텍스트란?

영속성 컨텍스트는 '엔티티를 영구 저장하는 환경'이라는 뜻을 가지고 있다.

이는 물리적으로 데이터베이스에 바로 저장되는 것이 아니라, 애플리케이션과 데이터베이스 사이에서 엔티티를 보관하고 관리하는 가상의 레이어라고 할 수 있다.

EntityManager.persist(entity); 코드는 엔티티 매니저를 사용해서 회원 엔티티를 영속성 컨텍스트에 저장한다.

 

💻 엔티티 매니저와의 관계

엔티티 매니저(Entity Manager)를 생성할 때 각각의 엔티티 매니저에는 고유의 영속성 컨텍스트가 만들어진다. 이 영속성 컨텍스트를 통해 엔티티 매니저는 엔티티들을 관리하며, 여기에 엔티티를 저장하거나 업데이트, 조회, 삭제 등의 작업을 수행한다. 

 

++) 여러 엔티티 매니저가 같은 영속성 컨텍스트에 접근할 수 있다. 

 

💻 엔티티의 생명주기

엔티티는 다음 네 가지 상태를 가질 수 있다:

• 비영속(New/Transient): 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태이다.

//객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

• 영속(Managed): 영속성 컨텍스트에 저장된 상태이다. 예를 들어, em.persist(member);를 호출하면 이 상태가 된다.

//객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

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

//객체를 저장한 상태(영속)
em.persist(member);

• 준영속(Detached): 영속성 컨텍스트에 저장되었다가 분리된 상태이다. 이 상태는 em.detach(member);, em.close();, 또는 em.clear();를 호출하면 발생한다.

//회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);

• 삭제(Removed): 영속성 컨텍스트와 데이터베이스에서 삭제된 상태이다.

//객체를 삭제한 상태(삭제)
em.remove(member);

 

💻 영속성 컨텍스트의 특징

• 식별자 값: 영속성 컨텍스트가 관리하는 모든 엔티티는 식별자 값을 가져야 한다.
• 트랜잭션 커밋 시 SQL 실행: 영속성 컨텍스트는 트랜잭션을 커밋하는 시점에 데이터베이스에 SQL을 실행하여 변경 사항을 반영한다.

 

💻 영속성 컨텍스트의 이점

• 1차 캐시
• 동일성(identity) 보장
• 트랜잭션을 지원하는 쓰기 지연 (transactional write-behind)
• 변경 감지 (Dirty Checking)
• 지연 로딩 (Lazy Loading)

1. 1차 캐시

영속성 컨텍스트는 내부적으로 1차 캐시를 사용하여 엔티티의 영속 상태를 관리한다. 1차 캐시는 '@Id'로 매핑된 필드를 키로 하고, 엔티티 인스턴스 자체를 값으로 가지는 Map 구조로 되어있다.

예를 들어,

//엔티티를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

//엔티티를 영속, 1차 캐시에 저장됨
em.persist(member);

//1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");

 

위 코드가 실행되면, 'Member' 엔티티는 영속성 컨텍스트의 1차 캐시에 저장된다.

 

그 후, 조회를 하려면 em.find로 1차 캐시에 있는 값을 가져오면 된다.

 

만약 1차 캐시에 조회하려는 값이 없다면 어떻게 될까?

 

예를 들어,

Member findMember2 = em.find(Member.class, "member2");

 

로 "member2"를 가져오려고 한다면,

1. 엔티티 조회 요청: em.find(Member.class, "member2") 메소드를 호출하여 Member 클래스의 인스턴스를 식별자 "member2"로 조회한다.
2. 1차 캐시 검사: 요청된 엔티티가 1차 캐시에 존재하는지 확인한다. member2가 캐시에 없으므로 DB조회로 넘어간다.
3. 데이터베이스 조회: member2가 1차 캐시에 없기 때문에 데이터베이스에서 직접 조회를 수행한다.
4. 엔티티 영속화: 조회한 데이터를 사용하여 Member 엔티티를 생성하고 이를 1차 캐시에 저장한다. 이 시점에서 member2는 영속 상태가 된다.
5. 엔티티 반환: 생성 및 저장 과정을 거친 영속화된 Member 엔티티를 반환한다.

그 다음에 또 "member2"를 한 번 더 조회하고 싶다면, 이미 1차 캐시에 저장되었기 때문에 다시 DB에 가서 조회할 필요가 없다.

 

2. 동일성 보장

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

System.out.println(a == b); //동일성 비교 true

 

JPA의 영속성 컨텍스트와 1차 캐시는 데이터베이스에서 처리되는 트랜잭션 격리 수준을 애플리케이션 차원에서 모방하여, 특히 반복 가능한 읽기(REPEATABLE READ) 격리 수준을 제공한다. 

따라서 a 와 b 를 동일성 비교하면 true가 나온다.

 

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

JPA에서 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)은 데이터베이스 작업의 효율성을 극대화하고 성능을 향상시키는 중요한 기능이다. 이 기능을 통해 엔티티의 변경 사항을 즉시 데이터베이스에 반영하지 않고, 트랜잭션이 커밋되는 시점에 일괄적으로 SQL을 전송한다.

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
//엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야 한다.
transaction.begin(); // [트랜잭션] 시작

em.persist(memberA);
em.persist(memberB);
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.

//커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋

 

먼저, 위와 같은 코드를 작성했다고 한다면, 

 

엔티티 등록

 

• 'em.persist(memberA)'와  'em.persist(memberB)'를 호출할 때, 해당 엔티티들의 INSERT SQL은 즉시 데이터베이스로 전송되지 않는다.
• 대신, 이 SQL문들은 영속성 컨텍스트 내의 쓰기 지연 SQL 저장소에 저장된다.

 

쓰기 지연 SQL 저장소

• 영속성 컨텍스트는 1차 캐시와 함께 쓰기 지연 SQL 저장소를 관리한다.
• 이 저장소는 트랜잭션 커밋 시까지 데이터베이스에 전송해야 할 모든 SQL 명령을 모은다.

트랜잭션 커밋

transaction.commit(); // 트랜잭션 커밋

 

• 트랜잭션이 커밋되는 순간, 영속성 컨텍스트는 저장소에 모인 SQL을 데이터베이스로 일괄 전송한다.
• 이 과정을 플러시(flush)이라고 하며, 영속성 컨텍스트의 변경 내용을 데이터베이스와 동기화한다.

쓰기 지연의 장점

쓰기 지연은 여러 가지 이점을 제공한다.

• 성능 최적화: 여러 변경 사항을 한 번에 데이터베이스로 전송함으로써 네트워크 비용과 데이터베이스 부하를 줄일 수 있다.
• 트랜잭션 관리 용이성: 개발자는 데이터베이스의 세부적인 작업에 신경 쓰지 않고, 엔티티의 상태만 관리하면 된다. 모든 변경은 트랜잭션이 성공적으로 완료될 때만 반영된다.

4. 변경 감지 (Dirty Checking)

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // [트랜잭션] 시작

// 영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

// 영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);

//em.update(member) 이런 코드가 있어야 하지 않을까?

transaction.commit(); // [트랜잭션] 커밋

 

엔티티를 수정하고자 할 때, 수정하고자 하는 값을 설정한 후에 "em.update(member)" 같은 코드가 있어야 할 것 같다는 생각이 든다. 

그러나 JPA를 이용하면 엔티티 값을 변경하거나 수정했을 때 em.persist() 또는 em.update()를 수행하지 않아도 DB에 변경이 반영된다. 

 

 

영속 엔티티 조회 및 수정

• 엔티티 매니저를 통해 영속성 컨텍스트 내에서 엔티티를 조회한다. 
• 조회된 엔티티의 데이터를 수정한다.

스냅샷 저장

• 영속성 컨텍스트는 엔티티의 원래 상태(스냅샷)를 내부적으로 저장한다. 
• 스냅샷이란 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해서 저장해둔 것이다. 즉 엔티티가 처음 로드될 때 생성된다.

트랜잭션 커밋 및 플러시

• 트랜잭션이 커밋되는 시점에 영속성 컨텍스트는 플러시되며, 변경된 엔티티를 스냅샷과 비교한다.
• 변경이 감지되면, 수정된 엔티티에 대한 적절한 SQL 업데이트 명령이 생성되어 쓰기 지연 SQL저장소에 추가된다.
• 저장소의 SQL은 데이터베이스로 전송되어 트랜잭션이 커밋된다.

---

💡플러시

 

플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 중요한 과정이다.

이 메커니즘을 통해 JPA는 애플리케이션의 상태와 데이터베이스의 상태를 동기화한다. 

💻  플러시의 주요 과정

1. 변경 감지(Dirty Checking):
   • 영속성 컨텍스트는 관리하고 있는 모든 엔티티의 현재 상태를 스냅샷(최초 저장된 상태)과 비교한다.
   • 변경된 엔티티가 감지되면, 해당 엔티티에 대한 적절한 수정 SQL을 생성하여 쓰기 지연 SQL 저장소에 등록한다.
2. 쓰기 지연 SQL 저장소 처리:
   • 쓰기 지연 SQL 저장소에 저장된 모든 SQL(등록, 수정, 삭제)을 데이터베이스로 전송한다.
   • 조회 쿼리는 저장되지 않으며, 필요 시 즉시 수행된다.

💻  플러시를 수행하는 방법

1. em.flush() - 직접 호출
   • 'EntityManager'의 'flush()' 메소드를 호출하여 영속성 컨테스트를 강제로 플러시한다. 일반적인 애플리케이션 개발에서는 드물게 사용되며, 특수한 상황이나 테스트 시에 활용된다.
2. 트랜잭션 커밋 - 플러시 자동 호출
   • 트랜잭션 커밋 시 자동으로 플러시가 수행된다. 이는 JPA가 트랜잭션의 완결성을 보장하기 위해 자동으로 데이터베이스에 변경 사항을 반영하기 위해 수행된다.
3. JPQL 쿼리 실행 - 플러시 자동 호출
   • JPQL이나 Criteria 쿼리 실행 전에 자동으로 플러시가 발생한다. 이는 쿼리 결과가 최신 상태를 반영하도록 하기 위해서이다. 예를 들어, 'persist()'로 영속화된 엔티티가 쿼리에 포함되도록 하기위해 필요하다.

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

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

💻  플러시 모드 옵션

• FlushModeType.AUTO (기본값): 트랜잭션 커밋이나 쿼리 실행 시 자동으로 플러시합니다.
• FlushModeType.COMMIT: 커밋 시에만 플러시를 수행합니다.

플러시 모드는 일반적으로 기본 설정을 사용하는 것이 좋으나, 특정 상황에서 성능 최적화나 동작 제어를 위해 변경할 수 있다.

em.setFlushMode(FlushModeType.COMMIT); // 플러시 모드를 커밋 시만 수행하도록 설정

 

💻  플러시는 !!

• 영속성 컨텍스트를 비우지 않는다.
• 영속성 컨텍스트의 변경내용을 데이터베이스에 동기화한다.
• 트랜잭션이라는 작업 단위가 중요하다. -> 커밋 직전에만 동기화하면 된다.

---

💡준영속 상태

준영속 상태는 영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 관리 범위에서 분리된 상태를 말한다.

이 상태의 엔티티는 더 이상 영속성 컨텍스트가 제공하는 생명주기 관리, 캐싱, 쓰기 지연, 변경 감지 등의 기능을 이용할 수 없다.

 

💻  준영속 상태로 전환하는 방법

Member member = em.find(Member.class, 150L);
member.setName("AAAA");

em.detach(member); //특정 엔티티만 준영속 상태로 전환
em.clear(); //영속성 컨텍스트를 완전히 초기화
em.close(); //영속성 컨텍스트를 종료

System.out.println(" ========== ");

tx.commit();

 

1. 특정 엔티티 분리 (em.detach(entity)):
   • 'EntityManager'의 'detach()' 메소드를 사용해 특정 엔티티를 준영속 상태로 전환한다. 이는 해당 엔티티를 영속성 컨텍스트의 관리에서 제거한다. 
    

em.detach(member)를 호출하면,

1. detach(memberA) 호출한다.
2. 1차 캐시에 memberA에 대한 정보를 제거한다.
3. 쓰기 지연 SQL 저장소에서 memberA 관련 SQL을 제거한다.

의 과정을 거치게 된다.

 

2. 영속성 컨텍스트 초기화 (em.clear()):

• 'clear()' 메소드는 영속성 컨텍스트를 완전히 초기화하여 관리하고 있던 모든 엔티티를 준영속 상태로 만든다.

영속성 컨텍스트가 완전히 초기화된 모습을 볼 수 있다.

 

3. 영속성 컨텍스트 종료 (em.close()):

• 'close()' 메소드는 영속성 컨텍스트를 종료하고, 이와 관련된 모든 엔티티를 준영속 상태로 전환한다.

영속성 컨텍스트가 완전히 종료되었다.

 

💻  준영속 상태의 특징

• 식별자 유지: 준영속 상태의 엔티티는 영속 상태일 때 할당받은 식별자 값을 유지한다.
• 기능 사용 불가: 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩 등 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
• 지연 로딩 불가: 준영속 상태의 엔티티는 지연 로딩을 수행할 수 없다. 실제 객체 대신 프록시를 로딩하는 지연 로딩은 영속성 컨텍스트를 필요로 하기 때문에, 준영속 상태에서는 문제가 발생할 수 있다.