엔티티 매니저 팩토리와 엔티티 매니저
엔티티 팩토리는 한 개만 생성되고, 엔티티 매니저는 여러개 생성되서 애플리케이션 전체에서 공유하도록 설계되어 있다.
엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하므로 서로 다른 스레드 간의 공유해도 되지만, 엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드 간에 절대 공유하면 안된다.
엔티티 매니저는 데이터베이스 연결이 필요한 시점까지 커넥션을 얻지 않는다. 보통 트랜잭션을 시작할 때 커넥션을 획득한다.
JPA 구현체들은 엔티티 매니저 팩토리를 생성할 때 커넥션풀을 만든다. (J2SE 환경)
영속성 컨텍스트
엔티티를 영구 저장하는 환경, 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.
- 여러 엔티티 매니저가 같은 영속성 컨텍스트에 접근할 수 있다.
엔티티의 생명주기
- 비영속 : 영속성 컨텍스트와 전혀 관계가 없는 상태
- 영속 : 영속성 컨텍스트에 저장된 상태
- 준영속 : 영속성 컨텍스트에 저장되었다가 분리된 상태
- 삭제 : 삭제된 상태
비영속
엔티티 객체를 생성하고, 아직 저장하지 않은 상태이다. 따라서 영속성 컨텍스트나 데이터베이스와는 전혀 관련이 없다.
영속
엔티티 매니저를 통해 엔티티를 영속성 컨텍스트에 저장한 상태이다.
영속성 컨텍스트가 관리하는 엔티티를 영속 상태라 한다.
저장 뿐 아니라 조회를 해도 영속 상태이다.
준영속
영속 상태의 엔티티를 영속성 컨텍스트가 관리하지 않으면 준영속 상태가 된다. detach(), close()를 호출해 영속성 컨텍스트를 닫거나, clear()를 호출해 영속성 컨텍스트를 초기화하면 준영속 상태가 된다.
삭제
엔티티가 영속성 컨텍스트와 데이터베이스에서 삭제된 상태이다.
영속성 컨텍스트의 특징
- 영속성 컨텍스트는 엔티티를 식별자 값(@Id)로 구분하기 때문에 반드시 식별자 값이 존재해야 한다.
- JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터베이스에 반영한다. → flush
- 1차 캐시
- 동일성 보장
- 트랜잭션을 지원하는 쓰기 지연
- 변경 감지
- 지연 로딩
엔티티 조회
영속성 컨텍스트는 내부에 1차 캐시를 가지고 있는데, 영속 상태의 엔티티는 모두 이곳에 저장된다. 1차 캐시에 있는 엔티티는 아직 데이터베이스에 반영되지 않은 상태이다. 내부에 Map으로 관리한다.
1차 캐시의 키는 식별자 값이고, 식별자 값은 데이터베이스 기본 키와 매핑되어 있다.
find()를 호출하면 먼저 1차 캐시에서 엔티티를 찾고, 1차 캐시에 없으면 데이터베이스에서 조회한다. 이때 데이터베이스에서 조회된 엔티티는 1차 캐시에 저장된 후 영속상태가 된다.
동일성 보장
1차 캐시에 있는 같은 엔티티를 조회하면 같은 인스턴스가 반환된다.
- 동일성 : 실제 인스턴스가 같다. ==
- 동등성 : 인스턴스는 다르지만 가지고 있는 값이 같다. equals()
- JPA는 1차 캐시를 통해 반복 가능한 읽기(REPEATABLE READ) 등급의 트랜잭션 격리 수준을 애플리케이션에서 제공해준다.
트랜잭션을 지원하는 쓰기지연
엔티티 매니저는 트랜잭션을 커밋하기 직전까지 내부 쿼리 저장소에 SQL을 모아둔다. 그리고 트랜잭션을 커밋할 때 쿼리를 데이터베이스에 내보낸다. 이것을 트랜잭션을 지원하는 쓰기 지연이라고 한다.
즉, 커밋할 때 영속성 컨텍스트를 플러쉬 한다.
- 플러쉬 : 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화 하는 작업 → 쓰기 지연 SQL 저장소에 모인 쿼리를 데이터베이스에 내보내는 작업
변경 감지
JPA는 엔티티를 영속성 컨텍스트에 보관할 때 최초 상태를 복사해서 저장해 두는데 이것을 스냅샷이라고 한다. 그리고 플러시 시점에 스냅샷과 엔티티를 비교해서 변경된 엔티티를 찾는다.
변경 감지는 영속 상태의 엔티티에만 적용된다.
JPA의 기본 전략은 수정된 필드 뿐만 아니라 모든 필드를 업데이트 한다.
- 모든 필드를 사용하면 수정 쿼리가 항상 같다. → 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용 가능
- 필드가 많거나 저장되는 내용이 너무 크면 수정된 데이터만 사용해서 동적으로 UPDATE SQL을 생성하는 전략을 선택(컬럼 30개 이상)
- @org.hibernate.annotations.DynamicUpdate
엔티티 삭제
엔티티를 삭제하려면 먼저 삭제 대상 엔티티를 조회해 영속 상태로 만들고, remove() 를 통해 엔티티를 넘겨주면 엔티티가 삭제된다.
쓰기 지연 SQL 저장소에 쿼리가 등록되고, 트랜잭션 커밋 후 플러시를 호출하면 삭제 쿼리를 전달한다.
remove()를 호출하는 순간 영속 상태에서 벗어나기 떄문에 재사용을 하지말고, 가바지 컬렉션의 대상이 되도록 두는 것이 좋다.
플러시
플러시(flush())는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.
- 변경 감지가 동작해 스냅샷과 비교, 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 등록
- SQL 저장소의 쿼리를 데이터베이스에 전송
플러시의 방법
- flush() 직접 호출
- 트랜잭션 커밋
- JPQL 쿼리 실행
JPQL이나 Criteria 같은 객체지향 쿼리를 호출할 때 플러시가 실행된다.
JPQL을 호출 할 때 데이터베이스에 반영되지 않은 엔티티가 있을 수 있기 때문에 JPQL 쿼리 실행 전 플러시를 호출한다.
플러시모드 옵션
- FlushModeType.AUTO : 커밋이나 쿼리를 실행할 때 플러시(default)
- FlushModeType.COMMIT : 커밋할 때만 플러시
플러시는 영속성 컨텍스트에 보관된 엔티티를 지우는 것이 아니라, 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화하는 것이다.
준영속
영속성 컨텍스트가 관리하는 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 것
준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.
- detach(entity) : 특정 엔티티만 준영속 상태로 전환
- clear() : 영속성 컨텍스트를 완전히 초기화한다.
- close() : 영속성 컨텍스트를 종료한다.
detach()
이 메서드를 호출하는 순간 1차 캐시부터 쓰기 지연 SQL 저장소까지 해당 엔티티를 관리하기 위한 모든 정보가 제거된다.
영속성 컨텍스트가 지원하는 기능이 동작하지 않는다.
clear()
영속성 컨텍스트가 초기화된다.
이로 인해 변경 감지는 동작하지 않고, 데이터베이스에도 반영되지 않는다.
close()
영속성 컨텍스트를 종료하면, 영속 상태의 엔티티가 모두 준영속이 된다.
준영속 상태의 특징
- 거의 비영속 상태에 가깝다 : 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩 기능이 동작하지 않는다.
- 식별자 값을 가지고 있다 : 비영속 상태는 식별자 값이 없다. 하지만 준영속 상태는 이미 한 번 영속상태였으므로 식별자 값이 있다.
- 지연 로딩을 할 수 없다 : 지연 로딩은 실제 객체 대신 프록시 객체를 로딩해두고 해당 객체를 실제 사용할 때 영속성 컨텍스트를 통해 데이터를 불러오는 방법이다.
merge()
준영속 상태의 엔티티를 다시 영속 상태로 변경하려면 병합을 사용해야 한다.
준영속 상태의 엔티티를 받아 그 정보로 새로운 영속 상태의 엔티티를 반환한다.
merge()는 비영속 엔티티도 영속 상태로 만들 수 있다.
식별자 값으로 엔티티를 조회할 수 있으면 불러서 병합하고, 조회할 수 없으면 새로 생성해서 병합한다. 따라서 병합은 save or update 기능을 수행한다.
출처 : 자바 ORM 표준 JPA 프로그래밍 - 김영한