[JPA 기본편] 영속성 관리 - 내부 동작 방식

웹 어플리케이션 개발을 한다고 하면 엔티티 매니저 팩토리가 고객의 요청이 올때마다 엔티티 매니저를 생성해서 내부적으로 DB와 커넥션을 생성하여 요청을 처리한다. 

 

영속성 컨텍스트

• 엔티티를 영구 저장하는 환경
• EntityManager.persist(entity);
  
  • 사실 DB에 저장한다는게 아니라 영속성 컨텍스트에 저장한다.
• EntityManager 안에 영속성 컨텍스트라는 보이지 않는 공간이 생긴다.
• 영속성 컨텍스트 내에 1차 캐시가 있어서 em.find()로 조회할 때, 1차 캐시에 있을 경우에는 select문이 안나간다. 
  • 하지만 1차 캐시는 하나의 트랜잭션 안에서만 효과가 있어서 성능적인 이점은 크게 있지는 않다.
• 영속 엔티티의 동일성 보장
  • 같은 primaryKey를 여러번 조회했을 때, ==으로 동일성을 비교하면 true가 나온다. 
• 엔티티 등록 시에 트랜잭션을 지원하는 쓰기 지연
  • persist()를 할 때 DB에 쓰는게 아니라 트랜잭션을 커밋할 때 insert sql을 보낸다.
  • persist()를 하면 쓰기 지연 SQL 저장소에 있다가 커밋할 때 플러시된다.
• 엔티티 수정 - Dirty Checking(변경 감지)
  • setter로 엔티티를 수정하면 em.update()이런 코드 없이도 알아서 처리해준다.
  • 커밋을 하면 내부적으로 플러쉬가 호출되는게 그 때 엔티티와 스냅샷(1차 캐시에 들어온 최초 시점)을 비교해서 다르면 쓰기 지연 SQL 저장소에 update 쿼리를 만들어 둔다.
• 엔티티 삭제는 엔티티를 find로 찾아와서 em.remove하면 된다. 그러면 트랜잭션 커밋 시점에 delete쿼리가 나간다. 

 

엔티티 생명 주기

• 비영속: 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
  
  • new로 생성 ~ setter로 설정
• 영속: 영속성 컨텍스트에 관리되는 상태
  • em.persist(entity)를 하면 엔티티 매니저 안에 있는 영속성 컨텍스트에 엔티티가 들어가면서 영속 상태가 된다.
• 준영속: 영속성 컨텍스트에 저장되었다가 분리된 상태
  • em.detach(entity);
• 삭제: 삭제된 상태 
  • em.remove(entity);

플러시

• 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영
• 플러시 발생 시 일어나는 일
  • Dirty Checking(변경 감지)
  • 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
  • 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송(등록, 수정, 삭제 쿼리)
• 플러시 호출 방법
  • em.flush() - 플러시 직접 호출 
  • 트랜잭션 커밋 - 플러시 자동 호출
  • JPQL 쿼리 실행 - 플러시 자동 호출
• 플러시는 영속성 컨텍스트를 비우지 않음
• 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화
• 트랜잭션이라는 작업 단위가 중요하다. 커밋 직전에만 동기화하면 된다.

 

 준영속 상태

• 영속 -> 준영속
  • em.detach(entity)
    • 특정 엔티티만 준영속 상태로
  • em.clear()
    • 영속성 컨텍스트를 초기화
  • em.close()
    • 영속성 컨텍스트를 종료
• 영속 상태의 엔티티가 영속성 컨텍스트에서 분리
• 영속성 컨텍스트가 제공하는 기능을 사용할 수 없음.