[JPA #2] 영속성 컨텍스트란?

.·2024년 7월 7일
JPA이론

JPA

목록 보기
2/6

영속성 컨텍스트 전에 JPA의 Entity Manager Factory, Entity Manager, Entity를 소개하면 아래와 같다.

엔티티 매니저 팩토리

//공장 만들기, 비용이 아주 많이 든다.
EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");
  • 이름 그대로 엔티티 매니저를 만드는 공장으로 만드는데 커넥션 풀도 함께 생성하므로 비용이 상당히 크다 ⇒ 따라서 한 개만 만들어서 공유해서 사용

엔티티 매니저

  • 반면 엔티티 매니저 팩토리를 통해서 엔티티 매니저를 생성할 때는 비용이 거의 들지 않음
  • 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드 간에 공유는 안 됨
  • J2SE 환경에서는 엔티티 매니저를 만들면 그 내부에 영속성 컨텍스트도 함께 만들어진다. 이 영속성 컨텍스트는 엔티티 매니저를 통해서 접근할 수 있다.

엔티티(@Entity)

  • 데이터베이스의 테이블과 매핑되는 자바 객체

    ⇒이를 통해 자바 애플리케이션에서 데이터베이스의 데이터를 객체로 다룰 수 있습니다.

영속성 컨텍스트란? ⇒ 엔티티를 영구 저장하는 환경

// 저장
em.persist(member);
  • persist() 메소드는 엔티티 매니저를 통해 회원 에티티를 영속성 컨텍스트에 저장한다.

엔티티의 생명주기

  1. 비영속(new / transient) : 영속성 컨텍스트와 전혀 관계가 없는 상태
  2. 영속(managed) : 영속성 컨텍스트에 저장된 상태
  3. 준영속(detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태
  4. 삭제(removed) : 삭제된 상태

  1. 비영속(new / transient) : 영속성 컨텍스트와 전혀 관계가 없는 상태
//객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
  1. 영속(managed) : 영속성 컨텍스트에 저장된 상태
  • 영속 상태라는 것은 영속성 컨텍스트에 의해 관리된다는 뜻
//객체를 저장한 상태(영속)
em.persist(member);
  1. 준영속(detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태
  • 특정 엔티티를 준영속 상태를 만들려면 detach, close, clear를 호출
//회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);

영속성 컨텍스트의 특징

  • 엔티티를 식별자 값(@id로 테이블의 기본 키와 매핑한 값)으로 구분한다.
    • 따라서 반드시 식별자 값이 반드시 있어야 함
  • 영속성 컨텍스트와 데이터베이스 저장
    • 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영하는데 이를 flush라고 한다.
  • 장점
    • 1차 캐시: 동일한 엔티티를 반복 조회할 때 데이터베이스 접근을 줄여 성능 향상.
    • 동일성 보장: 동일한 식별자를 가진 엔티티는 하나의 객체로 관리.
    • 트랜잭션을 지원하는 쓰기 지연: 변경 사항을 트랜잭션 종료 시 한꺼번에 반영.
    • 변경 감지: 엔티티 상태 변화를 자동으로 감지하고 데이터베이스에 반영.
    • 지연 로딩: 실제로 필요한 시점에 연관된 엔티티를 로드하여 초기 성능 향상.

엔티티 조회

  • 영속성 컨텍스트 내부에 캐시를 가지고 있는데 이걸을 1차 캐시라 한다.
  • 영속성 컨텍스트의 엔티티는 모두 1차 캐시에 저장이 된다.
  • em.find()를 통해 조회를 하면 먼저 1차 캐시에서 엔티티를 찾고 만약 없다면 데이터베이스에서 조회한다.

1차 캐시에서 조회

⇒ 그림과 같이 식별자 값으로 엔티티를 찾는다. (Map 형식)

데이터베이스에서 조회

  • 1차 캐시에 없으면 엔티티 매니저는 데이터베이스를 조회해서 엔티티를 생성한다. 그리고 1차 캐시에 저장한 후에 영속 상태의 엔티티를 반환한다.

엔티티 등록

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

//엔티티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다.
transaction.begin(); //[트랜잭션] 시작

em.persist(memberA);
em.persist(memberB);

//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.
//커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); //[트랜잭션] 커밋

  • 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소에 INSERT SQL을 차곡차곡 모아둔다.

  • 트랜잭션을 커밋하면 엔티티 매니저는 우선 영속성 컨텍스트를 플러시한다. 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 작업인데 이때 등록, 수정, 삭제한 엔티티를 데이터베이스에 반영한다.

⇒ 쓰기 지연 SQL 저장소에 모인 쿼리를 데이터베이스에 보내고 실제 데이터베이스 트랜잭션을 커밋한다.

엔티티 수정

  • SQL을 사용하면 수정 쿼리를 직접 작성해야 한다.

⇒이런 개발 방식의 문제점은 수정 쿼리가 많아지는 것은 물론이고 비즈니스 로직을 분석하기 위해 SQL을 계속 확인해야 한다. 결국 직접적이든 간접적이든 비즈니스로직이 SQL에 의존하게 된다.

그래서 JPA는 변경 감지를 통해 엔티티를 수정한다.

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

transaction.begin(); //[트랜잭션] 시작

//영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

//영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);

//em.update(member) 이런 코드가 있어야 하지 않을까?
transaction.commit(); //[트랜잭션] 커밋
  • JPA는 엔티티의 변경사항을 데이터베이스에 자동으로 반경하는 기능인 변경 감지를 제공한다.
  • 그래서 em.update(member)와 같은 코드가 필요 없이 단순히 데이터만 변경하면 된다.

  1. 트랜잭션을 커밋하면 엔티티 매니저 내부에서 먼저 플러시(flush())가 호출된다.
  2. 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾는다.
  3. 변경된 엔티티가 있으면 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보낸다.
  4. 쓰기 지연 저장소의 SQL을 데이터베이스에 보낸다.
  5. 데이터베이스 트랜잭션을 커밋한다.

⇒ 단, 변경 감지는 영속석 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용된다.

UPDATE MEMBER
SET
 NAME=?,
 AGE=?,
 GRADE=?,
 ...
WHERE
 id=?
  • 변경 감지로 인해 실행된 쿼리는 모든 필드를 사용해서 수정에 반영한다. 이렇게 하면 데이터 전송량이 증가하는 단점이 있지만 아래와 같은 장점이 있다.
  1. 수정 쿼리가 항상 같아서 애플리케이션 로딩 시점에 미리 생성해두고 재사용 가능하다.
  2. 데이터베이스에 동일한 쿼리를 보내면 이전에 한 번 파싱된 쿼리를 재사용할 수 있다.
  • 만약 필드가 많거나 저장되는 내용이 너무 크다면 동적으로 SQL을 생성하는 전략이 있다.
    • 단 이때는 하이버네이트 확장 기능을 사용
    • 상황에 따라 다르지만 컬럼이 대략 30개 이상이 되면 기본 방법인 정적 수정 쿼리보다@DynamicUpdate를 사용한 동적 수정 쿼리가 빠르다고 한다.

엔티티 삭제

Member memberA = em.find(Member.class, "memberA"); //삭제 대상 엔티티 조회

em.remove(memberA); //엔티티 삭제
  • 엔티티 등록과 비슷하게 삭제 쿼리를 쓰기 지연 SQL 저장소에 등록 ⇒ 이후 트랜잭션을 커밋해서 플러시를 호출하면 실제 데이터베이스에 삭제 쿼리를 전달한다.

플러시

  • 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다. 구체적으로는 아래와 같은 일이 일어난다.
  1. 변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 찾는다. 수정된 엔티티는 수정 쿼리를 만들어 쓰기 지연SQL 저장소에 등록한다.
  2. 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.

플러시하는 방법 3가지

  1. em.flush()를 직접 호출한다.
  2. 트랜잭션 커밋 시 플러시가 자동 호출된다.
  3. JPQL 쿼리 실행 시 플러시가 자동 호출된다.

준영속

  • 영속 상태의 엔티티가 영속석 컨텍스트에서 분리된 것을 준영속 상태라 한다. ⇒ 따라서 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
em.detach(entity) : 특정 엔티티만 준영속 상태로 전환
em.clear() : 영속성 컨텍스트를 완전히 초기화한다.
em.close() : 영속성 컨텍스트를 종료한다.

엔티티를 준영속 상태로 전환 : detach()

public void testDetached() {
 ...
 //회원 엔티티 생성, 비영속 상태
 Member member = new Member();
 member.setId("memberA");
 member.setUsername("회원A");
 
 //회원 엔티티 영속 상태
 em.persist(member);
 
 //회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
 em.detach(member);
 
 transaction.commit(); //트랜잭션 커밋
}
  • detach를 호출하는 순간 1차 캐시부터 쓰기 지연 SQL 저장소까지 해당 엔티티를 관리하기 위한 모든 정보가 제거된다.

⇒ 위에선 memberA Entity가 영속성 컨텍스트에서 분리되어 준영속 상태가 된다.

영속성 컨텍스트 초기화 : clear()

//엔티티 조회, 영속 상태
Member member = em.find(Member.class, "memberA");

em.clear(); //영속성 컨텍스트 초기화

//준영속 상태
member.setUsername("changeName");
  • 초기화로 영속성 컨텍스트를 제거하고 새로 만든 것과 같다.

⇒ 위에선 member의 이름을 변경해도 데이터베이스에 반영되지 않는다.

영속성 컨텍스트 종료 : close()

  • em.close로 영속성 컨텍스트를 종료시킴

⇒ 영속성 컨텍스트가 종료되어 더는 memberA, memberB가 관리되지 않는다.

‼ 영속 상태의 엔티티는 주로 영속성 컨텍스트가 종료되면서 준영속 상태가 된다. 개발자가 직접 준영속 상태로 만드는 일은 드물다.

준영속 상태 특징

  1. 거의 비영속 상태에 가깝고 영속성 컨텍스트의 어떠한 기능도 동작하지 않는다.
  2. 식별자 값을 가지고 있다.
  3. 지연 로딩을 할 수 없다.

병합 : merge()

  • 준영속 상태의 엔티티를 다시 영속 상태로 변경하려면 merge를 사용한다.

    ⇒ 준영속 상태의 엔티티를 받아서 그 정보로 새로운 영속 상태의 엔티티를 반환한다.

  • 참고로 병합은 비영속 엔티티도 영속 상태로 만들 수 있다.

profile
.
Tech
이전 포스트

[JPA #1] JPA란 무엇인가?

다음 포스트

[JPA #3] 연관관계 매핑(단반향 / 양방향 / 연관관계 주인)

0개의 댓글