3장. 영속성 관리

본 포스트는 사내 스터디로 진행되는 자바 ORM 표준 JPA 프로그래밍 관련 정리입니다

 

인프런 강의도 있습니다! 짱짱

https://www.inflearn.com/course/ORM-JPA-Basic

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

---

3장. 영속성 관리

• 엔티티 매니저
  • 엔티티를 저장하고 수정하고, 삭제하고, 조회하는 엔티티를 관리하는 관리자
  • 가상의 데이터베이스로 생각하면 된다
  • 여러 스레드가 공유하면 동시성 문제가 발생 ( 절대 공유하면 안된다 )
  • 데이터베이스 연결이 꼭 필요한 시점까지 커넥션을 획득하지 않는다 ( 트랜잭션이 시작할때 획득 )
• 엔티티 매니저 팩토리
  • EntityManagerFactory, 생성하는데 비용이 많이 들기 때문에 어플리케이션 당 일반적으로 하나만 생성
  • 엔티티 매니저가 필요할 때마다 EntityManagerFactory를 통해 EntityManager를 생성하면 된다
    
    

    // Create EntityManager
    EntityManager em = entityManagerFactory.createEntityManager();​

    
    
    
  • EntityManagerFactory에서 EntityManager를 생성하는 비용은 거의 들지 않는다
  • 여러 쓰레드가 공유해도 안전하다
    
  • 보통의 JPA 구현체(하이버네이트 포함)들은 EntityManagerFactory를 생성할 때 DB 커넥션풀도 생성
    

 

 

 

영속성 컨텍스트

• 엔티티를 영구 저장하는 환경
• 논리적인 개념에 가깝고 눈에 보이지 않는다
• 엔티티 매니저를 생성할 때 하나 만들어진다

• 영속성 컨텍스트 생명주기 정리
  • 비영속: 영속성 컨텍스트와 전혀 관계 없는 상태
    
  • 영속: 영속성 컨텍스트에 저장된 상태
  • 준영속: 영속성 컨텍스트에 저장되었다가 분리된 상태
  • 삭제: 삭제된 상태
    

 

 

• 비영속 상태
  • 순수한 객체 상태
  • 아직 영속성 컨텍스트에 의해 관리되지 않는 상태
    
    

    // create Object
    Member member = new Member();
    member.setId("member1");
    member.setUserName("회원1");​

• 영속 상태
  • 영속성 컨텍스트가 관리하는 엔티티
    
    

    // managed entity
    em.persist(member);​

    
    
    
• 준영속 상태
  • 영속성 컨텍스트에 의해 관리되던 엔티티(영속 상태)가 관리를 끊으면 준영속 상태
    
    

    // divide
    em.detach(member);​

    
    
    
• 삭제
  • 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제한다
    
    

    // delete entity
    em.remove(member);​

     

 

 

영속성 컨텍스트의 특징

• 영속성 컨텍스트는 엔티티를 식별자 값(@Id로 테이블 PK와 매핑한 값)으로 구분한다 ( 반드시 식별자 값이 있어야 한다 )
• 트랜잭션이 커밋하는 순간 flush가 되어 DB에 반영된다 ( 함수를 호출한다고 바로 DB반영 X )
• 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 등을 지원 ( 자세한건 뒤에서... )

 

• 1차 캐시
  • 영속성 컨텍스트가 내부에 가지고 있는 캐시
  • Map 형태로 @Id로 매핑한 식별자를 Key로 엔티티 인스턴스를 Value로 저장한다
  • 엔티티 조회를 요청하면, 먼저 1차 캐시에 저장된 엔티티를 찾고(메모리), 없으면 DB를 조회하여 1차캐시에 저장후 Return한다
  • DB를 거치지 않으니, 성능상의 이점이 있다
• 동일성 보장
  • 같은 식별자를 가진 엔티티를 반복해서 호출해도 항상 동일한 인스턴스를 보장한다
  • 동일성 vs 동등성
    • 동일성: 실제 인스턴스가 같은 것 ( == 비교 )
    • 동등성: 인스턴스가 가지고 있는 값이 같다 ( equals 메서드 )
• 쓰기 지연
  • 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 쿼리르 보내지 않고 쓰기 지연 저장소에 모아둔다
  • 트랜잭션이 커밋될때 한번에 모아둔 쿼리를 보낸다
  • 트랜잭션 커밋하면 엔티티매니저는 우선 영속성 컨텍스트를 플러시한다 ( 쓰기 지연 저장소에 있는 쿼리 적용 )
  

 

• 변경 감지
  • JPA로 엔티티를 수정할 때는 단순히 엔티티를 조회해서 데이터만 변경하면 된다
  • JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해서 스냅샷을 만들어 보관한다
  • 변경 감지 동작 순서
    1. 트랜잭션 커밋
    2. 엔티티 매니저 내부에서 먼저 flush가 호출
    3. 현재 저장된 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾는다
    4. 변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보낸다
    5. 쓰기 지연 저장소의 SQL을 데이터베이스에 보낸다
    6. 데이터베이스 트랜잭션을 커밋
  • 변경 감지는 영속 상태의 엔티티에만 적용된다
  • JPA의 기본 전략은 엔티티의 모든 필드를 업데이트한다
    • 모든 필드를 사용하면 수정 쿼리가 같다 ( 어플리케이션 로딩시점에서 수정 쿼리를 미리 생성해두고 재사용 가능 )
    • 데이터베이스에 동일 쿼리를 보내면 데이터베이스는 이전에 파싱된 쿼리를 재사용 가능
    • 내용이 너무 크면 @DynamicUpdate, @DynamicInsert 사용 ( 컬럼 30개 이상정도 권장 )

 

플러시

• 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스 반영한다
• 동작 순서
  1. 변경 감지 동작으로 영속성 컨텍스트에 있는 모든 엔티티를 돌며 스냅샷과 비교
  2. 수정된 엔티티가 있다면 수정쿼리를 만들어 쓰기지연 SQL 저장소에 쿼리(Update) 등록
  3. 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송(CRUD)
• 호출 방법
  • em.flush()
  • 트랜잭션 커밋시 자동 호출
  • JPQL 쿼리 실행 시 플러시가 먼저 자동 호출
    • JPQL은 데이터베이스에 직접 질의를 하는 것이므로 먼저 쓰기지연 저장소 쿼리들이 반영이되어야 정합성을 맞출 수 있다
• 옵션
  • FlushModeType.AUTO: 커밋이나 쿼리를 실행할 때 플러시 ( default )
  • FlushModeType.COMMIT: 커밋할 때만 플러시
• 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 것 ( 지우는 것이 아니다 )

 

준영속

• 영속성 컨텍스트 초기화: clear()
  • 영속성 컨텍스트를 초기화해서 들어있는 모든 엔티티를 준영속 상태로 만든다
• 영속성 컨텍스트 종료: close()
  • 관리하던 영속 상태의 엔티티가 모두 준영속 상태가 되고 더이상 EntityManager를 사용 불가
• 준영속 상태의 특징
  • 거의 비영속 상태에 가깝다
    • 영속성 컨텍스트가 관리하지 않으므로, 1차 캐시, 쓰기 지연, 변경 감지 등등의 영속성 컨텍스트가 제공하는 어떠한 기능도 사용할 수 없다
  • 식별자 값을 가지고 있다
    • 준영속 상태는 이미 한 번 영속 상태 였으므로 항상 식별자 값을 가지고 있다
  • 지연 로딩시 문제가 발생
    • 지연 로딩은 실제 객체 대신 Proxy 객체를 로딩해 놓고 실제 사용할 때 데이터를 불러오는 기법이나 해당 엔티티가 준영속 상태라면 데이터를 불러올 수 없다
• 병합
  • merge()
  • 준영속 상태의 엔티티를 다시 영속 상태로 변경하기 위해 사용
  • 준영속 상태의 엔티티를 받아서 그 정보로 새로운 영속 상태의 엔티티를 반환한다
    • 즉.. 인자로 보낸 엔티티 객체와 반환되는 엔티티 객체가 다른 객체이다
  • 동작 순서
    • merge() 실행
    • 파라미터로 들어온 엔티티의 식별자로 1차 캐시에서 엔티티 조회
    • 없다면 데이터베이스에 질의후 1차 캐시에 저장
    • 조회한 엔티티의 스냅샷 저장(DB 데이터 기준)후 인자로 들어온 엔티티의 내용을 채워넣는다
    • 엔티티 반환(인자로 들어온 엔티티가 아니라 조회한 엔티티를 반환)
    • commit시 변경감지로 동작한 update 쿼리가 나간다