[JPA] 영속성 컨텍스트란 무엇일까❓ #2(1차 캐시, 변경 감지, 쓰기지연 감소)

📌 JPA에서 영속성 컨텍스트는 데이터베이스와 객체 사이의 상호작용을 효율적으로 관리하기 위해 만들어진 핵심적인 공간입니다.

 

영속성 컨텍스트는 Entity 객체의 상태를 관리하고, 데이터베이스와의 상호작용을 최적화하여 성능을 향상시킵니다.

 

JPA를 사용하면서 여러분이 자주 접하게 될 1차 캐시, 변경 감지, 쓰기 지연 감소는 이 영속성 컨텍스트의 중요한 기능들입니다.

 

이번 포스팅에서는 영속성 컨텍스트가 이러한 기능들을 통해 어떻게 Entity 객체를 효율적으로 관리하고, 성능을 극대화하는지에 대해 자세히 살펴보겠습니다.

 

 

JPA에서 영속성 컨텍스트의 핵심 기능_1차 캐시

영속성 컨텍스트는 내부적으로 캐시 저장소를 가지고 있습니다. 우리가 저장하는 Entity 객체들이 1차 캐시 즉, 캐시 저장소에 저장되게 됩니다.

캐시 저장소는 Map 자료구조 형태로 되어있습니다.

• key
  • @Id로 매핑한 기본 키 즉, 식별자 값을 저장합니다.
• value
  •  해당 Entity 클래스의 객체를 저장합니다.
• 영속성 컨텍스트는 캐시 저장소 Key에 저장한 식별자값을 사용하여 Entity 객체를 구분하고 관리합니다.

---

 

영속성 컨텍스트는 1차 캐시를 사용하여 엔티티 객체를 관리합니다. 이 캐시는 다음과 같은 기능을 제공합니다.

Entity 객체의 저장

• 영속성 컨텍스트는 데이터베이스에서 조회한 엔티티 객체를 1차 캐시에 저장합니다.
• 이 캐시는 영속성 컨텍스트의 lifecycle동안 유지됩니다.

중복 조회 방지

• 동일한 엔티티에 대한 여러 번의 조회를 방지합니다.
• 1차 캐시에 저장된 엔티티 객체는 중복으로 조회되지 않으며, 데이터베이스 조회를 최소화합니다.

성능 향상

• 1차 캐시를 사용하면 동일한 트랜잭션 내에서 데이터베이스에 대한 중복 요청을 줄일 수 있으며, 성능을 향상시킵니다.

자동 동기화

• 엔티티의 상태가 변경되면, 영속성 컨텍스트는 자동으로 이를 반영하며, 트랜잭션 커밋 시 변경 사항을 데이터베이스에 저장합니다.

동일성 보장 

@Test
@DisplayName("객체 동일성 보장")
void test4() {
    EntityTransaction et = em.getTransaction();

    et.begin();
    
    try {
        Memo memo3 = new Memo();
        memo3.setId(2L);
        memo3.setUsername("Robbert");
        memo3.setContents("객체 동일성 보장");
        em.persist(memo3);

        Memo memo1 = em.find(Memo.class, 1);
        Memo memo2 = em.find(Memo.class, 1);
        Memo memo  = em.find(Memo.class, 2);

        System.out.println(memo1 == memo2);
        System.out.println(memo1 == memo);

        et.commit();
    } catch (Exception ex) {
        ex.printStackTrace();
        et.rollback();
    } finally {
        em.close();
    }

    emf.close();
}

---

 

위 실행결과를 보면

• 같은 값을 조회하는 memo1과 memo2는 == 결과 true를 반환합니다.
• memo1과 다른 값을 조회하는 memo는 == 결과 false를 반환합니다.

 

근데 이상한점이 있습니다. 자바를 배울 때 객체를 두개 생성했을 때 두 개의 주소는 같을 수 없다고 알고 있습니다.

 

그러나 JPA의 영속성 컨텍스트와 관련하여 find() 메서드를 호출할 때, 같은 식별자(PK)를 가진 엔티티를 조회하면 두 객체가 같은 인스턴스를 참조하는 경우가 있습니다.

 

이 현상은 JPA의 1차 캐시 기능으로 설명할 수 있습니다.

 

구체적으로, 1차 캐시는 영속성 컨텍스트 내에서 동일한 식별자를 가진 Entity가 하나만 존재하도록 보장합니다. 이를 통해 엔티티의 동일성 보장과 중복 조회 방지 기능이 구현됩니다.

 

즉 정리하자면 다음과 같습니다.

• 영속성 컨텍스트 내에서 동일한 식별자를 가진 엔티티는 하나의 인스턴스만을 가지며, 모든 조회는 이 단일 인스턴스를 반환합니다. 따라서 1차 캐시는 영속성 컨텍스트 내에서 엔티티의 동일성을 보장합니다.

---

영속성 컨텍스트의 캐시 저장소 활용

영속성 컨텍스트가 이 캐시 저장소를 어떻게 활용하고 있는지 실제 코드를 보면서 확인해 보겠습니다.

 

Entity저장

---

@Test
@DisplayName("1차 캐시 : Entity 저장")
void test1() {
    EntityTransaction et = em.getTransaction();

    et.begin();

    try {

        Memo memo = new Memo();
        memo.setId(1L);
        memo.setUsername("Robbie");
        memo.setContents("1차 캐시 Entity 저장");

        em.persist(memo);

        et.commit();

    } catch (Exception ex) {
        ex.printStackTrace();
        et.rollback();
    } finally {
        em.close();
    }

    emf.close();
}

 

em.persist(memo); 메서드가 호출되면 memo Entity 객체를 캐시 저장소에 저장합니다.

 

캐시 저장소 저장 결과

위 "캐시 저장소 저장 결과"를 보면 em ➡️ persistenceContext ➡️ entitiesBykey를 확인해 보면 key-value 형태로 정보가 저장되어 있음을 확인할 수 있습니다.

---

Entity조회

Entity조회 같은 경우에는 크게 두가 지 경우로 나뉘게 됩니다.

 

1. 캐시 저장소에 조회하는 Id가 존재하지 않은 경우

@Test
@DisplayName("Entity 조회 : 캐시 저장소에 해당하는 Id가 존재하지 않은 경우")
void test2() {
    try {

        Memo memo = em.find(Memo.class, 1);
        System.out.println("memo.getId() = " + memo.getId());
        System.out.println("memo.getUsername() = " + memo.getUsername());
        System.out.println("memo.getContents() = " + memo.getContents());


    } catch (Exception ex) {
        ex.printStackTrace();
    } finally {
        em.close();
    }

    emf.close();
}

---

1. 캐시 저장소 조회

1. 1차 캐시에서 찾는다.

---

2. DB SELECT 조회 후 캐시 저장소에 저장

2. DB에서 찾는다.

 

find() 메서드를 사용하여 조회를 할 수 있습니다.

 

만약 위 그림처럼 id : 1인 PK를 가지고 조회를 하는데 1차 캐시에 없으면 DB에 SELECT쿼리를 보내게 됩니다. DB에서 조회를 하고 그 값을 1차 캐시에 저장을 합니다.

 

그리고 1차 캐시에 저장되어 있는 Entity값을 반환하여 EntityManager한테 반환하여 이 값을 사용하도록 합니다.

 

 

위 결과를 보면 find() 메서드를 보내고 1차 캐시에 없기 때문에 DB에 Select문을 보내고 다시 1차 캐시에 저장하고 이 1차 캐시에 저장되어 있는 Entity값을 반환하여 EntityManger가 사용한 것을 볼 수 있습니다.

---

2. 캐시 저장소에 조회하는 Id가 존재하는 경우

 

캐시 저장소에 조회하는 식별자 값이 1이고, Memo Entity타입 인 값이 있다면 해당 Entity 객체를 바로 반환합니다.

---

@Test
@DisplayName("Entity 조회 : 캐시 저장소에 해당하는 Id가 존재하는 경우")
void test3() {
    try {

        Memo memo1 = em.find(Memo.class, 1);
        System.out.println("memo1 조회 후 캐시 저장소에 저장\n");

        Memo memo2 = em.find(Memo.class, 1);
        System.out.println("memo2.getId() = " + memo2.getId());
        System.out.println("memo2.getUsername() = " + memo2.getUsername());
        System.out.println("memo2.getContents() = " + memo2.getContents());


    } catch (Exception ex) {
        ex.printStackTrace();
    } finally {
        em.close();
    }

    emf.close();
}

 

 

위 실행결과를 보면 한 번의 Select가 보내진 것을 알 수 있습니다. 이는 위 코드에서 find() 메서드로 DB에서 select로 조회를 하고 1차 캐시로 가져온 데이터를 memo2가 다시 한번 find() 했기 때문입니다.

 

---

Entity삭제

1.Entity 조회 및 캐시 저장소 확인

 

Entity를 삭제하기 위해서는 먼저 해당 Entity가 영속성 컨텍스트의 1차 캐시에 있는지 확인합니다.

 

만약 캐시 저장소에 존재하지 않는다면, JPA는 데이터베이스에서 해당 Entity를 조회하여 캐시 저장소에 저장합니다.

 

 

em.remove(entity) 메서드를 호출하면, JPA는 해당 Entity를 삭제할 준비를 합니다.

 

remove() 메서드는 삭제할 Entity를 영속성 컨텍스트 내에서 DELETED 상태로 변경하며, 실제 데이터베이스의 변경 사항은 트랜잭션이 커밋될 때 적용됩니다.

 

트랜잭션이 커밋되면, JPA는 데이터베이스에 DELETE SQL 명령을 발송하여 해당 Entity를 삭제합니다.

 

---

@Test
@DisplayName("Entity 삭제")
void test5() {
    EntityTransaction et = em.getTransaction();

    et.begin();

    try {

        Memo memo = em.find(Memo.class, 2);

        em.remove(memo);

        et.commit();

    } catch (Exception ex) {
        ex.printStackTrace();
        et.rollback();
    } finally {
        em.close();
    }

    emf.close();
}

 

JPA에서 Entity를 삭제하기 위한 과정은 다음과 같습니다.

1. Entity 조회
2. 먼저, em.find(EntityClass.class, PK) 메서드를 사용하여 특정 Entity를 조회합니다. 예를 들어, PK가 2인 Memo 객체를 조회한다고 가정할 때, 결과는 Memo#2가 됩니다. 이 시점에서 이 Entity는 관리(MANAGED) 상태로, 영속성 컨텍스트에 의해 관리되고 있음을 나타냅니다.

 

위 디버깅 결과를 보면 먼저, em.find(EntityClass.class, PK) 메서드를 사용하여 특정 Entity를 조회합니다.

 

위 코드를 기준으로, PK가 2인 Memo 객체를 조회하고 있습니다. 결과는 Memo#2가 됩니다. 이 시점에서 이 Entity는 관리(MANAGED) 상태로, 영속성 컨텍스트에 의해 관리되고 있음을 나타냅니다.

 

 

Entity를 삭제하기 위해 em.remove(entity) 메서드를 호출합니다. 이 메서드 호출 후, Entity의 상태는 DELETED로 변경됩니다.

 

DELETED 상태는 해당 Entity가 삭제 대기 중임을 의미합니다. 실제 삭제 작업은 트랜잭션이 커밋(COMMIT)될 때 데이터베이스에 DELETE SQL 쿼리가 발송되면서 이루어집니다.

 

 

위 최종 결과를 보면 select로 데이터가 존재하는지 확인하고 delete 쿼리가 동작한 것을 볼 수 있습니다.

 

 

쓰기 지연 저장소  (Write-Behind Storage)란❓

 

JPA의 트랜잭션 처리 방식에서는 SQL 명령을 모아서 일괄적으로 데이터베이스에 적용하는 방식이 핵심적인 역할을 합니다.

 

이러한 접근 방식은 성능을 최적화하고 데이터베이스와의 상호작용을 효율적으로 관리하는 데 중요한데, 그 과정에서 중요한 역할을 하는 개념이 바로 쓰기 지연 저장소(Write-Behind Cache)입니다.

 

쓰기 지연 저장소❓는 JPA의 영속성 컨텍스트에서 변경된 Entity 상태를 메모리에 임시로 저장하는 구조를 의미합니다.

 

데이터베이스에 직접적인 반영을 지연시키고, 트랜잭션이 커밋될 때 변경 사항을 일괄적으로 처리하여 효율적인 데이터베이스 관리와 성능 향상을 가져옵니다.

 

 

쓰기 지연 저장소  (Write-Behind Storage)의 주요 개념

변경 사항의 임시 저장

Entity의 상태를 변경할 때, JPA는 그 변경 사항을 즉시 데이터베이스에 반영하는 대신, 쓰기 지연 저장소에 임시로 저장합니다. 이를 통해 빈번한 데이터베이스 접근을 줄이고, 메모리에서 변경 사항을 관리합니다.

 

트랜잭션 커밋 시점에 반영

쓰기 지연 저장소에 저장된 변경 사항은 트랜잭션이 커밋될 때 데이터베이스에 실제로 반영됩니다.

 

JPA는 이 시점에 모든 변경 사항을 일괄적으로 처리하여, 데이터베이스에 적절한 SQL 명령(INSERT, UPDATE, DELETE)을 발송합니다.

 

성능 향상

쓰기 지연 저장소를 사용하면 데이터베이스와의 상호작용을 최적화하고 성능을 개선할 수 있습니다. 메모리에 임시로 저장된 변경 사항을 한 번에 처리함으로써, 데이터베이스의 부하를 줄이고 전체적인 성능을 향상합니다.

 

 

쓰기 지연 저장소  (Write-Behind Storage)의 동작 방식

@Test
@DisplayName("쓰기 지연 저장소 확인")
void test6() {
    EntityTransaction et = em.getTransaction();

    et.begin();

    try {
        Memo memo = new Memo();
        memo.setId(2L);
        memo.setUsername("Robbert");
        memo.setContents("쓰기 지연 저장소");
        em.persist(memo);

        Memo memo2 = new Memo();
        memo2.setId(3L);
        memo2.setUsername("Bob");
        memo2.setContents("과연 저장을 잘 하고 있을까?");
        em.persist(memo2);

        System.out.println("트랜잭션 commit 전");
        et.commit();
        System.out.println("트랜잭션 commit 후");

    } catch (Exception ex) {
        ex.printStackTrace();
        et.rollback();
    } finally {
        em.close();
    }

    emf.close();
}

---

 

위 디버깅 실행결과를 보면 쓰기 지연 저장소(actionQueue)를 보면 바로 데이터 베이스에 반영되지 않고 insertions에 변경 사항이 저장이 저장된 것을 볼 수 있습니다.

---

commit() 메서드 실행 후(commit 후)

 

지연 저장소(actionQueue)에 임시로 저장되어 있던 insertions 데이터가 사라진 것을 볼 수 있습니다.

 

---

 

실제 기록을 확인해 보면, 트랜잭션 커밋 전까지 SQL 요청이 없던 것이, 커밋 후 한 번에 INSERT SQL 두 개가 순서대로 데이터베이스에 요청된 것을 볼 수 있습니다.

 

flush() 메서드

flush() 메서드는 JPA의 EntityManager에서 중요한 역할을 하는 메서드로, 영속성 컨텍스트의 변경 사항을 데이터베이스에 반영하는 과정을 제어합니다. 이를 통해 데이터베이스와의 동기화를 명시적으로 수행할 수 있습니다.

 

즉, 쓰기 지연 저장소의 SQL들을 DB에 요청하는 역할을 수행합니다.

 

flsuh() 메서드가 실제로 어떻게 동작하는지 직접 호출해 보면

 

@Test
@DisplayName("flush() 메서드 확인")
void test7() {
    EntityTransaction et = em.getTransaction();

    et.begin();

    try {
        Memo memo = new Memo();
        memo.setId(4L);
        memo.setUsername("Flush");
        memo.setContents("Flush() 메서드 호출");
        em.persist(memo);

        System.out.println("flush() 전");
        em.flush(); // flush() 직접 호출
        System.out.println("flush() 후\n");
        

        System.out.println("트랜잭션 commit 전");
        et.commit();
        System.out.println("트랜잭션 commit 후");

    } catch (Exception ex) {
        ex.printStackTrace();
        et.rollback();
    } finally {
        em.close();
    }

    emf.close();
}

 

 

• 엔티티 상태의 변경
  • 코드에서 memo 엔티티를 생성하고, 이를 영속성 컨텍스트에 저장하기 위해 em.persist(memo)를 호출합니다. 이 엔티티는 영속성 컨텍스트의 쓰기 지연 저장소에 저장됩니다.

 

---

 

flush() 메서드 호출을 호출하면, 영속성 컨텍스트에 저장된 변경 사항이 데이터베이스에 즉시 반영된 것을 볼 수 있습니다.

 

이 시점에서, JPA는 쓰기 지연 저장소에 있는 INSERT SQL 명령을 데이터베이스에 요청합니다. 이로 인해 데이터베이스의 상태는 memo 엔티티의 변경 사항을 포함하게 됩니다.

 

 

변경 감지(dirty checking)란❓

JPA에서 엔티티의 상태가 변경될 때마다 UPDATE SQL이 쓰기 지연 저장소에 저장된다면, 비효율적인 상황이 발생할 수 있습니다.

 

여러 번의 UPDATE SQL이 각각 데이터베이스에 요청되면, 데이터베이스와의 통신 비용이 증가하고 성능에 악영향을 미칠 수 있습니다. 이러한 문제를 방지하기 위해JPA는 변경 감지 기능(dirty checking)을 제공합니다.

 

 

변경 감지(Dirty Checking)는 JPA의 핵심 기능 중 하나로, 엔티티의 상태 변경을 자동으로 추적하고 효율적으로 데이터베이스에 반영하는 역할을 합니다.

 

변경 감지(dirty checking)의 동작 방식

 

변경 감지(Dirty Checking)와 엔티티의 상태를 관리하기 위해 JPA는 LoadedState와 같은 개념을 활용합니다.

 

JPA는 영속성 컨텍스트에 엔티티를 저장할 때, 최초 상태(LoadedState)를 기록합니다.

 

이후 트랜잭션이 커밋되거나 em.flush()가 호출되면 JPA는 엔티티의 현재 상태와 최초 상태를 비교하여, 변경된 부분을 효율적으로 처리합니다. 이 과정을 변경 감지(Dirty Checking)라고 부릅니다.

 

그러면 실제로 동작하는 과정은 다음과 같습니다.

---

@Test
@DisplayName("변경 감지 확인")
void test8() {
    EntityTransaction et = em.getTransaction();

    et.begin();

    try {
        System.out.println("변경할 데이터를 조회합니다.");
        Memo memo = em.find(Memo.class, 4);
        System.out.println("memo.getId() = " + memo.getId());
        System.out.println("memo.getUsername() = " + memo.getUsername());
        System.out.println("memo.getContents() = " + memo.getContents());

        System.out.println("\n수정을 진행합니다.");
        memo.setUsername("Update");
        memo.setContents("변경 감지 확인");

        System.out.println("트랜잭션 commit 전");
        et.commit();
        System.out.println("트랜잭션 commit 후");

    } catch (Exception ex) {
        ex.printStackTrace();
        et.rollback();
    } finally {
        em.close();
    }

    emf.close();
}

 

• 엔티티 조회 및 초기 상태 출력
  • em.find(Memo.class, 4)를 통해 엔티티를 조회합니다. 이때 엔티티는 영속성 컨텍스트에 의해 관리됩니다.
  • 조회된 엔티티의 현재 상태(memo.getUsername(), memo.getContents())를 출력합니다. 이 상태는 LoadedState로, 엔티티의 초기 상태를 나타냅니다.
• 엔티티 상태 변경
  • memo.setUsername("Update")와 memo.setContents("변경 감지 확인") 메서드를 호출하여 엔티티의 상태를 변경합니다. 이 시점에서 엔티티의 상태는 Managed 상태에서 변경되었으며, JPA는 이 변경 사항을 감지합니다.

 

 

 

• 트랜잭션 커밋
  • et.commit()을 호출하면, JPA는 현재 상태와 최초 상태를 비교하여 변경된 부분만을 포함하는 UPDATE SQL을 생성합니다.
  • 이 UPDATE SQL은 쓰기 지연 저장소에 저장된 후, 데이터베이스에 전송되면서 실제로 상태가 업데이트됩니다.
• 결과 확인
  • 트랜잭션 커밋 후 UPDATE SQL이 데이터베이스에 요청된 것을 확인할 수 있습니다. 이는 JPA가 자동으로 변경 사항을 감지하고 처리했음을 의미합니다.