반응형
Notice
Recent Posts
Recent Comments
관리 메뉴

간단한 개발관련 내용

2장 JPA 시작 & 3장 영속성 관리 본문

IT 책/JPA (ORM 표준 JPA 프로그래밍)

2장 JPA 시작 & 3장 영속성 관리

vincenzo.dev.82 2024. 11. 19. 13:04
반응형

2장 JPA 시작


 

2.1 이클립스 설치와 프로젝트 불러오기

2.2 H2 데이터베이스 설치

2.3 라이브러리와 프로젝트 구조

2.3.1 메이븐 사용과 라이브러리 관리

2.4 객체 매핑 시작

2.5 persistence.xml 설정

2.6 애플리케이션 개발

2.6.1 엔터티 매니저 설정

  • 엔터티 매니저 팩토리 생성
    • 설정 정보를 읽어서 JPA를 동작시키기 위한 기반 객체를 만들고 JPA 구현체에 따라서는 데이터베이스 커넥션 풀도 생성하므로 엔터티 매니저 팩토리를 생성하는 비용은 아주 크다. 따라서 엔터티 매니저 팩토리는 애플리케이션 전체에서 딱 한 번만 생성하고 공유해서 사용해야 한다.
  • 앤터티 매니저 생성
    • 엔터티 매니저 팩토리에서 엔터티 매니저를 생성한다. JPA의 기능 대부분은 이 엔터티 매니저가 제공한다. 대표적으로 엔터티 매니저를 사용해서 엔터티를 데이터베이스에 등록/수정/삭제/조회 할 수 있다. 엔터티 매니저는 내부에 데이터소스(데이터베이스 커넥션)을 유지하면서 데이터베이스와 통신한다. 참고로 엔터티 매니저는 데이터베이스 커넥션과 밀접한 관계가 있으므로 스레드 간에 공유하거나 재사용해서는 안 된다.
  • 종료
    • 마지막으로 사용이 끝난 엔터티 매니저는 반드시 종료해야 한다.
    • em.close();
    • 왜냐하면 커넥션과 관련이 있기 때문에~

2.6.2 트랜잭션 관리

2.6.3 비즈니스 로직

2.6.4 JPQL

  • 애플리케이션이 필요한 데이터만 데이터베이스에서 불러오려면 결국 검색 조건이 포함된 SQL을 사용해야 한다. JPA는 JPQL 이라는 쿼리 언어로 이러한 문제를 해결한다.
  • JPQL은 엔터티 객체를 대상으로 쿼리
  • SQL은 데이터베이스 테이블을 대상으로 쿼리

2.7 정리

 


 

3장 영속성 관리


3.1 엔터티매니저 팩토리와 앤터티 매니저

<aside> 💡

엔터티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하므로 서로 다른 스레드 간에 공유해도 되지만, 엔터티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드 간에 절대공유하면 안 된다.

</aside>

 

3.2 영속성 컨텍스트란?

  • 엔터티를 영구히 저장하는 환경

3.3 엔터티의 생명주기

  • 비영속(new / transient)
    • 영속성 컨텍스트와 전혀 상관없는 상태
  • 영속(managed)
    • em.persist()
  • 준영속(detached)
    • em.detatched(), em.close(), em.clear()
  • 삭제(removed)
    • em.remove()

3.4 영속성 컨텍스트의 특징

  • 영속성 컨텍스트와 식별자 값
    • 엔터티를 식별자값으로 구분한다
      • @Id로 테이블의 기본 키와 매핑한 값
  • 영속성 컨텍스트와 데이터베이스 저장
    • persist()
    • flush()
  • 영속성 컨텍스트가 엔터티를 관리하면 다음과 같은 장정이 있다.
    • 1차 캐시
    • 동일성 보장(엔터티의 동일성 보장)
    • 트랜잭션을 지원하는 쓰기 지연
    • 변경 감지
    • 지연 로딩

3.4.1 엔터티 조회

  • 1차 캐시의 키는 식별자 값이다. 그리고 식별자 값은 데이터베이스 기본 키와 매핑되어 있다. 따라서 영속성 컨텍스트에 데이터를 저장하고 조회하는 모든 기준은 데이터베이스 기본 키 값이다.
  • em.find() 1차캐시 조회 후 없으면 DB
  • 영속성 컨텍스트를 성능상 이점과 엔터티의 동일성을 보장한다

<aside> 💡

JPA는 1차 캐시를 통해 반복 가능한 읽기(REPEATABLE READ) 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공한다는 장점이 있다.

</aside>

3.4.2 엔터티 등록

  • 쓰기지연 SQL 저장소
  • 트랜잭션을 지원하는 쓰기 지원(transactional write-behind)
  • 모아둔 등록 쿼리를 데이터베이스에 한 번에 전달하여 성능을 최적화 할 수 있다

3.4.3 엔터티 수정

  • 변경감지(dirty checking)는 영속성 컨텍스트가 관리하는 영속 상태의 엔터티에만 적용되는데, 엔터티의 변경 사항을 데이터베이스에 자동으로 반영한다.
  • 최초 스냅샷과 변경된 엔터티를 비교
  • @DynamicUpdate를 통해 변경된 필드만 쿼리되도록 함

3.4.4 엔터티 삭제

  • em.remove()
  • 삭제 쿼리를 쓰기 지연 저장소에 전달

3.5 플러시

  • 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다
  • 플러시 방법 3가지
    • em.flush()
    • 트랜잭션 커밋 시
    • JPQL 쿼리 실행 시 플러시 자동 호출

3.5.1 플러시 모드 옵션

3.6 준영속

  • 준영속 상태의 엔터티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
    • em.detach(entity)
    • em.clear() : 영속성 컨텍스트를 완전히 초기화한다
    • em.close() : 영속성 컨텍스트를 종료한다

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

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

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

3.6.4 준영속 상태의 특징

  • 거의 비영속 상태에 가깝다
  • 식별자 값을 가지고 있다
  • 지연 로딩을 할 수 없다

3.6.5 병합 : merge()

  • 준영속 상태의 엔터티를 다시 영속 상태로 변경한다
  • 병합은 준영속, 비영속을 신경 쓰지 않는다. 식별자 값으로 엔터티를 조회할 수 있으면 불러서 병합하고 조회할 수 없으면 새로 생성해서 병합한다. 따라서 병합은 save or update 기능을 수행한다

3.7 정리

  • 엔터티 매니저는 엔터티 매니저 팩토리에서 생성한다. 자바를 직접 다루는 J2SE 환경에서는 엔터티 매니저를 만들면 그 내부에 영속성 컨텍스트도 함께 만들어진다. 이 영속성 컨텍스트는 엔터티 매니저를 통해서 접근할 수 있다.
  • 영속성 컨텍스트는 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. 영속성 컨텍스트 덕분에 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩 기능을 사용할 수 있다.
  • 영속성 컨텍스트에 저장한 엔터티는 플러시 시점에 데이터베이스에 반영되는데 일반적으로 트랜잭션을 커밋할 때 영속성 컨텍스트가 플러시된다.
  • 영속성 컨텍스트가 관리하는 엔터티를 영속상태의 엔터티라 하는데, 영속성 컨텍스트가 해당 엔터티를 더 이상 관리하지 못하면 그 엔터티는 준영속 상태의 엔터티라 한다. 준영속 상태의 엔터티는 더는 영속성 컨텍스트의 관리를 받지 못하므로 영속성 컨텍스트가 제공하는 1차캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기지연, 변경감지, 지연로딩 같은 기능들을 사용할 수 없다.
반응형