[필기용] 자바 ORM 표준 JPA 프로그래밍 Ch03

git : https://github.com/Dev-Chaee/Java_JPABook/tree/ch03-jpa

CHAPTER 03

• 영속성 상태는 jpa가 객체를 관리하는 상태이다.
  • persist를 한 객체는 영속성 객체가 되며 JPA가 관리를 한다.
  • 객체만 생성을 한 경우에는 비영속성이라고 칭한다.
  • 준영속과 삭제 상태도 있다.

• JPA에서 중요하게 봐야하는 부분은 1차 캐시 영역이라고 생각한다.
  • 1차 캐시 영역이란?
    • JPA가 관리하는 영속성 객체의 경우 1차 캐시영역에 저장을 한다. 이는 쉽게 생각해서 MAP이라고 생각을 하면 된다
      만약 persist로 영속성 객체로 만든 경우 1차 캐시 영역에 데이터를 저장한다. 이를 조회할때 JPA는 먼저 1차 캐시 영역에서 데이터를 조회한다.
      찾는 데이터가 있을 경우 DB에 접근하지 않고 그대로 반환하고 데이터가 없을 경우 DB에 접근을 한다.

• commit
  • persist를 하여 영속성 상태로 만든다고 하더라도 JPA에서는 관련된 SQL을 생성하여 "쓰기지연SQL저장소"에 SQL을 저장만해둔다.
    이를 실제로 사용하는 것은 commit() 함수를 실행할 때 쓰기지연 저장소에 있는 SQL을 사용한다.

• 엔티티 수정 (변경감지)
  • 트랜잭션을 커밋하면 먼저 플러시가 실행된다. -> 엔티티와 스냅샷을 비교하여 변경된 엔티티를 찾는다. ->
    변경된 엔티티가 있으면 수정쿼리를 생성해서 쓰기 지연 저장소에 쿼리를 보낸다. -> sql을 db로 보낸다 -> 트랜잭션을 커밋한다.

• JPA는 기본적으로 업데이트 쿼리를 생성할 때 모든 필드를 업데이트 하는 것이 기본 전략이다. 이는 아래의 장점으로 인하여 그렇다.
  • 모든 필드를 사용하면 수정 쿼리가 항상 같으므로 로딩 시점에 쿼리를 미리 생성해두고 재사용할 수 있어서.
  • 디비에 동일한 쿼리를 보내면 디비는 이전에 한 번 파싱된 쿼리를 재사용 할 수 있어서
  • 만약 필드가 너무 많거나 저장되는 데이터의 내용이 너무 크면 수정된 데이터만 사용해서 동적으로 쿼리를 생성하는 전략을 쓰면 된다.
    • @org.hibernate.annotations.DynamicUpdate
    • 필드가 약 30개 정도가 넘어간다면 다이나믹업데이트 어노테이션을 사용하는 것이 적절하다.
  • JPQL 실행 시 플러시는 자동호출된다.

• 엔티티 삭제
  • 먼저 삭제를 하려면 find를 통해 삭제할 엔티티 객체를 찾아야 한다. remove 메소드를 통해 삭제할 경우
    영속성 컨텍스트에서 제거가 되며 커밋이 호출되는 시점에 데이터가 삭제가 된다. remove 메소드를 사용했다면 해당 엔티티 객체는 재사용을 하지 않는 것이 좋다.

• 엔티티 준영속
  • 영속 상태의 엔티티를 준영속 상태로 변경하면 1차 캐시영역에서 엔티티가 제거된다.
  • 준영속 상태로 변경하는 함수
    • detach : 영속성 컨텍스트 안에 특정 엔티티를 매개변수로 넘기면 해당 엔티티가 준영속 상태가 된다.
    • clear : 영속성 컨텍스트 안에 있는 모든 엔티티가 준영속 상태가 된다.
    • close : 영속성 컨텍스트 관리가 종료되며 모든 엔티티가 준영속 상태가 된다.
  • 영속성 컨텍스트를 만드는 것은 개발자가 직접하는 일은 드물다. 주로 영속성 컨텍스트가 종료되며 자동으로 관리가 된다.

• 준영속 상태의 특징
  • 비영속 상태에 가깝다. 다만 식별자 값은 가지고 있다.
  • 지연 로딩을 사용할 수 없다.

• 병합 : 준영속 상태의 엔티티를 영속성으로 변경
  • merge(객체)를 주면 영속성 컨텍스트에서 다시 관리가 된다.
  • 병합은 준영속 상태뿐만이 아닌 비영속 상태의 엔티티도 영속 상태로 변경할 수 있다.
  • 병합은 파라미터로 넘어온 엔티티의 식별자 값으로 영속성 컨텍스틀 조회하고 없으면 DB에서도 조회를 한다.
    만약 둘 다 없으면 새로운 엔티티를 생성하여 병합한다. 따라서 병합은 save or update 기능을 수행한다고 생각하면 된다.