2. 영속성 컨텍스트(캐시, 동일성 보장, 변경 감지, 트랜잭션 지연)

영속성(Persistence)

: 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성

- 영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에, 프로그램이 종료되면 모두 잃어버림

-> 파일 시스템, 관계형 데이터베이스를 활용하여 데이터를 영구적으로 저장하고 영속성을 부여

 

영속성 레이어

: 프로그램의 아키텍처에서 데이터에 영속성을 부여해주는 계층

- JDBC를 이용하여 직접 구현할 수 있지만 Persistance Framework를 이용한 개발이 많이 이루어짐

- JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로 DB와 연동되는 시스템을 빠르게 개발할 수 있으며, 안정적인 구동을 보장함

 

영속성 컨텍스트

: 애플리케이션와 DB 사시에서 엔티티와 레코드의 괴리를 해소하는 기능과 객체를 보관하는 기능을 수행

- 엔티티 객체가 영속성 컨텍스트에 들어오면 JPA는 엔티티 객체의 매핑 정보를 DB에 반영하는 작업을 수행

- 영속 객체

: 엔티티 객체가 영속성 컨텍스트에 들어와 JPA의 관리 대상이 되는 시점부터 객체를 부르는 호칭

- 엔티티를 영구 저장하는 환경으로 엔티티 매니저를 통해 영속성 컨텍스트에 접근

- 세션 단위의 생명주기를 가짐 )

• DB에 접근하기 위한 세션이 생성되면 영속성 컨텍스트가 반들어짐
• 세션이 종료되면 영속성 컨텍스트도 없어짐
• 엔티티 매니저는 이러한 일련의 과정에서 영속성 컨텍스트에 접근하기 위한 수단으로 사용됨

 

Entity의 생명 주기

• New / Transient
  • 비영속 상태
  • Entity가 생성, 영속성 컨텍스트에 저장되지 않은 상태
  • new 키워드를 통해 생성된 상태로 영속성 컨텍스트와 관련이 없는 상태
• Managed
  • 영속 상태
  • Entity 매니저로 영속성 컨텍스트에 저장된 상태
  • DB에 반영되지 않고 영속성 컨텍스트에 의해 관리됨
  • 트랜잭션 커밋 시점에 DB에 반영
• Detached
  • 준영속 상태
  • 영속성 컨텍스트에 의해 관리되다가 분리된 상태
• Removed
  • 삭제된 상태
  • 영속성 컨텍스트와 DB에서 제거된 상태

영속성 컨텍스트의 특징

1. 식별자 값

- 영속성 컨텍스트는 식별자 값(PK)로 Entity를 구분

- 모든 영속 상태의 Entity는 식별자 값을 가지고 있어야 함

- 없다면 예외를 뱉어냄

 

2. 커밋 & 플러시

- 영속성 컨텍스트에 Entity를 저장하고 트랜잭션을 커밋해야 실제 DB에 반영됨

- Flush : 현재 영속성 컨텍스트의 변경 내용을 DB에 반영하는 작업

- Commit : 트랜잭션의 작업을 최종적으로 DB에 반영하는 과정

-> 트랜잭션에 포함된 논리 작업 단위를 성공적으로 수행했고, 데이터가 무결성을 준수한다면 Commit을 통해 DB에 반영

 

cf) Commit vs Flush

- Flush는 쿼리를 전송하는 역할 -> 임시저장

- Commit은 Flush를 수행하고 트랜잭션을 끝내는 역할

 

3. 1차 캐시

- 영속성 컨텍스트 내부에는 Entity 인스턴스를 캐싱하는 1차 캐시가 있음

- 일반적으로 트랜잭션 내에서 유효한 생명 주기를 가짐

- 같은 트랜잭션 내에서 1차 캐시에 존재하는 Entity를 조회할 때, DB에 접근하지 않아도 됨

- 트랜잭션이 커밋되면 소멸함

 

cf) 트랜잭션

: DB에서 한 번에 실행되어야 할 여러 작업들이 묶인 논리적인 작업 단위

- 데이터의 일관성과 무결성을 보장하는 데 매우 중요한 역할을 함

 

4. 동일성 보장

- 1차 캐시에서는 Entity 인스턴스를 Map 구조로 캐싱함

- 따라서 같은 식별자를 통해 1차 캐시에서 얻은 Entity 인스턴스는 == 연산을 통해 동일성을 보장

 

5. 쓰기 지연

- 트랜잭션 내에서 영속화된 Entity에 대한 쿼리를 쓰기 지연 SQL 버퍼에 저장해두었다가 commit이나 flush 시점에 DB로 요청함

 

6. 변경 감지

- Entity 인스턴스를 영속성 컨텍스트에 보관할 때, 최초 상태에 대한 스냅샷을 저장해둠

- 커밋 또는 플러시 시점에 각각의 Entity 상태를 스냅샷과 비교하는데 변경된 Entity가 있으면 쓰기 지연 SQL 버퍼에 update 쿼리를 추가함

 

 

 

 

 

 

 

 

 

 

Reference

https://mooonstar.tistory.com/entry/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98%EC%9D%98-%ED%95%B5%EC%8B%AC-Commit%EA%B3%BC-Rollback-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0