[JPA] 영속성 컨텍스트

Spring 프레임워크에서는 데이터베이스와 연동되어 데이터가 바뀌는 비즈니스 로직을 처리합니다. 데이터베이스와 연동하는 방법은 JDBC를 설치하고 쿼리를 작성하면 됩니다. 이때 Mybatis를 사용할 수도 있고 JPA를 사용할 수도 있습니다. 

 

오늘은 Spring DATA JPA를 이용한 데이터베이스 연동을 할 때 내부에서 동작하는 과정 및 이슈에 대해 알아보려 합니다.

 

JPA는 데이터베이스의 테이블을 엔티티라는 객체로 자바 애플리케이션에서 관리합니다. 이때 엔티티를 영속하게 관리하는데 이를 영속성 컨텍스트가 관리합니다. 그리고 JPA에서 자동으로 SQL문을 생성하고 데이터베이스에 질의를 날립니다. 영속한 엔티티는 영속성 컨택스트에서 관리되는데 몇 가지 상태를 가집니다.

---

엔티티의 상태

• 비영속(New)
  • 영속성 컨텍스트에서 관리된 경험이 없는 엔티티로 새로 생성된 엔티티의 상태입니다.
• 영속(Managed)
  • 영속성 컨텍스트에 의해 관리되는 엔티티의 상태입니다.
• 준영속( Detached)
  • 영속성 컨텍스트에 의해 관리된 경험이 있는 엔티티입니다.
• 삭제(Remove)
  • 삭제된 엔티티의 상태입니다.

 

영속성 컨텍스트는 소스코드에서 EntityManager로 접근하고 제어할 수 있습니다. 또는 엔티티에 정의된 함수를 실행해서 영속성 컨텍스트를 동작하게 할 수 있습니다.

엔티티 생명주기

---

영속성 컨텍스트의 기능

1차 캐시 영역

영속성 컨텍스트에는 1차 캐시 영역에서 엔티티 정보를 최신 정보로 유지하려 합니다. 이 동작은 데이터베이스 하나의 트랜잭션에서 이루어집니다. 조회 시 엔티티가 1차 캐시 영역에 있다면 해당 엔티티를 리턴하고 1차 캐시 영역에 없다면 데이터베이스에서 조회를 하게 됩니다.

 

동일성 보장

1차 캐시 영역은 엔티티매니저가 flush를 실행하지 않는 한 DB와 동기화하지 않습니다. 그렇기 때문에 하나의 트랜잭션 내에서 1차 캐시 영역에 저장되는 엔티티는 항상 같습니다.

 

쓰기지연

영속성 컨텍스트는 엔티티매니저의 모든 동작은 DB에 곧바로 반영하지 않습니다. 이것은 데이터베이스의 트랜잭션과 비슷합니다. 쓰기 지연에는 주로 Insert, Update, Delete 쿼리가 쌓여있다가 commit이 실행되거나 flush 또는 JPQL 쿼리가 실행되면 쓰기지연에 쌓여있는 쿼리를 DB에 반영하고 동기화합니다.

 

변경감지(Dirty Check)

1차 캐시 영역은 스냅샷으로 저장되며 항상 최신의 상태를 유지해야 합니다. find()로 1차 캐시 영역에 존재하는 엔티티를 리턴해주기 위해서 엔티티가 소스코드 내에서 수정되는지 항상 확인해야 합니다. 그렇기 때문에 setter로 스냅샷이 더럽혀지면 더티체킹이 실행되고 Update 쿼리를 실행하여 데이터베이스와 동기화하고 1차 캐시영역을 최신 정보로 유지합니다.

---

Insert와 Update

JPA에서는 해당 비즈니스 로직이 끝나면 save()를 호출하게 됩니다.

 

save 하는 엔티티가 새로 생성된 엔티티인가 영속성 컨텍스트에서 관리된 엔티티인가에 따라 persist()나 merge()가 실행됩니다. EntityInfomation객체에서 isNew() 상태값으로 확인할 수 있지만 영속성 컨텍스트에서 관리된 엔티티임은 보장할 수 없습니다.

 

새로 생성된 엔티티여서 persist()가 실행되면 insert 쿼리를 보낼 것이고 이미 관리된 엔티티여서 merge()가 실행되면 update 쿼리를 보낼 것입니다.