영속성 컨텍스트
Entity Manager Factory, Entity Manager?
-JPA는 스레드가 하나 생성될 때 마다(매 요청 마다) EntityManager Factory에서 Entity Manger를 생성한다.
-Entity Manager는 내부적으로 DB 커넥션 풀을 사용해서 DB에 붙는다.
Entity Manager Factory
- 엔티티 매니저를 만드는 공장이라고 볼 수 있다.
- 엔티티 매니저 팩토리는 생성하는 비용이 크기 때문에 한 개만 만들어서 애플리케이션 전체에서 공유한다.
- 여러 스레드가 동시에 접근해도 안전하다.
Entity Manager
- 엔티티의 CRUD 등등 엔티티와 관련된 모든 일을 처리한다.
- 엔티티 매니저는 여러 스레드가 동시에 접근할 경우 동시성 문제가 발생하기 때문에 스레드 간에 공유해서는 안된다.
영속성(Persistence)
데이터를 생성한 프로그램이 종료되어도 사라지지 않는 데이터의 특성을 뜻한다.
영속성을 갖지 않는다면? 데이터는 메모리에서만 존재하고, 프로그램이 종료되면 해당 데이터는 모두 사라진다.
그렇기 때문에 데이터를 DB 또는 파일에 저장해서 데이터에 영속성을 부여하는 것이다.
영속성 컨텍스트란?
JPA를 이해하는데 가장 중요한 용어이다.
엔티티를 영구 저장하는 환경이라는 뜻이다.
엔티티를 담고 있는 집합으로 JPA는 영속성 컨텍스트에 속한 엔티티를 DB에 반영한다.
영속성 컨텍스트는 엔티티 매니저를 생성할 때 하나만 만들어진다.
엔티티 매니저를 통해서만 영속성 컨텍스트에 접근이 가능하다.
EntityManager.persist(entity);앞서 위의 코드를 살펴 봤었는데, 즉 엔티티 매니저를 사용해서 엔티티를 데이터 베이스에 저장하는게 아니라 영속성 컨텍스트에 저장한다.
엔티티의 생명주기
1. 비영속(new/transient) : 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태이다.(그냥 객체를 생성한 상태)
2. 영속(managed) : 영속성 컨텍스트에 저장되는 상태이다.(객체를 저장한 상태)
//객체를 생성한 상태가 비영속 상태이다.
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
EntityManager em = emf.createEntityManager();
em.getTransaction().begin():
//이렇게 객체를 저장한 상태는 영속상태가 되는 것이다.
em.persist(member);3. 준영속(detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태이다.
4. 삭제(removed) : 삭제된 상태이다.
영속성 컨텍스트의 이점은 무엇일까?
- 1차 캐시와 동일성을 보장한다.
- 트랜잭션을 지원하는 쓰기지연
- 변경 감지(Dirty Checking)
- 지연 로딩(Lazy Loading)
1차 캐시란?
- 영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이것을 1차 캐시라고 한다.
- 영속 상태의 엔티티가 모두 이곳에 저장된다.
- 키는 @Id로 매핑한 식별자이며, 값은 엔티티 인스턴스이다.
엔티티 조회
엔티티 조회, 1차캐시
//엔티티를 생성한 상태로 비영속 상태이다.
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
//엔티티를 영속
em.persist(member);엔티티가 영속상태가 됐을 때 위의 그림과 같이 영속성컨텍스트의 1차캐시에 저장된 모습을 볼 수 있다.
1차캐시에서 조회
Member member = new Member();
member.setId("memberId");
member.setUsername("회원1");
//1차 캐시에 저장된다.
em.persist(member);
//1차 캐시에서 조회한다.
Member findMember = em.find(Member.class, "member1");
엔티티를 조회하는 find 메서드가 실행되면 먼저 1차 캐시에서 식별자 값으로 엔티티를 찾는다.
찾는 엔티티가 1차 캐시에 있는 경우 DB를 조회하지 않고 메모리에 있는 1차 캐시에서 엔티티를 조회한다.
DB에서 조회
하지만 1차캐시에 찾는 엔티티가 없는 경우에는 데이터 베이스에서 조회해서 가져온 후에 1차 캐시에 저장하고 영속상태의 엔티티를 반환한다.
아래그림이 해당설명의 그림이다.
Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member2");
System.out.println(a == b); //true앞선 게시글에서도 자주 보았던 코드이다. 위의 경우에 참이라는 사실은 알고있다. 1차 캐시에 있는 같은 엔티티 인스턴스를 반환하기 때문이다.
그럼 영속성 컨텍스트에 member1이 없는 경우에도 과연 참일까?
정답은 참이다.
그 이유는 엔티티 매니저가 데이터베이스에서 member1을 조회해서 1차 캐시에 저장하고 반환할 것이고, 이후 두 번째 요청시에는 1차 캐시에 있는 member1 엔티티 인스턴스를 반환하기 때문이다.
엔티티 등록
트랜잭션을 지원하는 쓰기 지연
아래는 엔티티 매니저를 사용해서 엔티티를 영속성 컨텍스트에 등록하는 코드이다.
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = en.getTransaction();
//엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야한다.
transaction.begin(); //트랜잭션 시작
em.persist(memberA);
em.persist(memberB);
//여기까지 INSERT SQL을 데이터 베이스에 보내지 않는다.
//커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); //트랜잭션 커밋엔티티 매니저는 트랜잭션을 커밋하기 전까지 데이터베이스에 엔티티를 저장하지 않고, 내부 저장소에 INSERT SQL을 모아둔 뒤에 트랜잭션 커밋하는 순간 모아둔 쿼리를 데이터 베이스에 보내서 저장시킨다.
이것이 바로 트랜잭션을 지원하는 쓰기 지연이다.
persist(memberA)가 실행되면, 영속성 컨텍스트는 1차캐시에 memberA에 대한 엔티티를 저장함과 동시에 JPA가 이 엔티티를 분석해서 쓰기 지연 SQL 저장소에 INSERT SQL 쿼리를 저장한다.
이 때 아직 DB에는 INSERT 쿼리를 보내지 않았다.
memberB도 동일하게 저장된다.
그럼 커밋하는 순간을 그림으로 알아보자.
트랜잭션을 commit 하는 순간 엔티티 매니저는 영속성 컨텍스트를 flush한다.
쓰기지연 저장소에 있던 쿼리들이 실제로 DB에 날라가는 것이다.
엔티티 수정
SQL을 사용하면 수정사항이 있을 경우 수정에 관한 쿼리를 직접 작성해야하고 프로젝트 규모가 커질수록 수정 쿼리도 늘어날 것이며 점점 복잡해 질 것이다.
이러한 방식의 문제점은 비즈니스 로직이 SQL에 의존하게 된다는 것이다.
하지만 JPA는 변경감지라는 기능이 있다.
변경 감지(Dirty Checking)
- 변경감지는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용된다.
- 비영속 상태의 엔티티나 준영속 상태의 엔티티 처럼 영속성 컨텍스트의 관리를 받지 않는 경우의 엔티티는 값을 변경해도 데이터베이스에 반영되지 않는다.
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin() // 트랜잭션 시작
// 영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");
// 영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);
//우리가 기존에 SQL을 사용했을 때 했던 방법처럼 em.update(member)같은 코드가 있어야하지 않나?
transaction.commit(); // 트랜잭션 커밋위의 코드를 보면 update와 관련된 메서드는 없다.
memberA에 대한 setter로 값을 변경했는데 DB에는 어떻게 엔티티가 수정이 되는 것인지 의문이 생긴다.
단지 저 코드만으로 수정이 가능한 이유는 JPA에 변경감지(Dirty Checking) 기능이 있기 때문이다.
변경감지는 엔티티의 변경 사항을 자동으로 데이터베이스에 반영하는 기능이다.
그럼 변경감지는 어떻게 동작하는 것일까?
JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태를 복사해서 저장해 두며 이것을 스냅샷이라고 한다.
동작 순서
1. 트랜잭션을 커밋하면 엔티티 매니저 내부에서 플러시가 호출된다.
2. 엔티티와 스냅샷을 비교하여 변경된 엔티티가 있는지 확인한다.
3. 변경된 엔티티가 있는 경우에 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보낸다.
4. 쓰기 지연 저장소의 SQL을 데이터 베이스에 보낸다.
5. 데이터 베이스 트랜잭션을 커밋한다.
변경감지로 인해 실행된 UPDATE SQL은 변경된 부분만 쿼리가 생기는 것이 아닌 이를 포함한 엔티티의 모든 필드를 함께 업데이트 한다.
데이터 전송량이 증가한다는 단점이 있지만 모든 필드를 사용하면 수정쿼리가 같기 때문에 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용 할 수 있다.
엔티티 삭제
//삭제대상 엔티티 조회
Member memberA = em.find(Member.class, "memberA");
em.remove(memberA); //엔티티 삭제em.remove에 삭제 대상 엔티티를 넘겨주면 엔티티를 삭제한다.
바로 삭제되는 것이 아니라 이때는 영속성 컨텍스트에서만 제거되고, 삭제쿼리를 쓰기 지연 저장소에 등록한 뒤에 트랜잭션을 커밋해서 플러시를 호출하면 실제 데이터 베이스에 삭제 쿼리를 전달해서 삭제된다.
플러시
플러시(flush)
-영속성 컨텍스트의 변경 내용을 데이터 베이스에 반영하는 것이다.
플러시 발생
- 플러시를 실행하면 변경 감지가 동작해서 영속성 컨텍스트의 있는 엔티티들을 스냅샷과 비교해서 수정된 엔티티를 찾는다.
- 수정된 엔티티를 쓰기 지연 SQL에 등록한다.
- 쓰기지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.(등록, 수정, 삭제 쿼리)
영속성 컨텍스트를 플러시하는 방법
- em.flush() : 직접 호출
엔티티 매니저의 flush() 메서드를 직접 호출해서 영속성 컨텍스트를 강제로 플러시하는 방법이다. - 트랜잭션 커밋 : 플러시 자동 호출
JPA는 트랜잭션을 커밋할 때 플러시를 자동으로 호출해서 영속성 컨텍스트의 변경내용을 데이터 베이스에 반영하도록 한다. - JPQL 쿼리 실행 : 플러시 자동호출
JPQL이나 Criteria 같은 객체지향 쿼리를 호출할 때도 플러시가 실행된다.
플러시 모드 옵션
- FlushModeType.AUTO : 커밋이나 쿼리를 실행할 때 플리시(기본값이다.)
- FlushModeType.COMMIT : 커밋할 때만 플러시한다는 것.
플러시 특징
- 영속성 컨텍스트를 비우는 것이 아니다. 단지 쓰기 지연 SQL 저장소에 있는 것들이 DB에 반영되는 것이다.
- 영속성 컨텍스트의 변경내용을 데이터 베이스에 동기화 한다.
- 트랜잭션이라는 작업단위가 중요하다. 커밋직전에만 동기화 하면 된다.
준영속 상태
- 영속상태의 엔티티가 영속성 컨텍스트에서 분리(detached)된 상태이다.
- 영속성 컨텍스트가 제공하는 기능을 아무것도 사용하지 못한다.
준영속 상태로 만드는 방법
- em.datach(entity) : 특정 엔티티만 준영속 상태로 전환한다.
- em.clear() : 영속성 컨텍스트를 완전히 초기화 한다.
- em.close() : 영속성 컨텍스트 종료
이 경우 영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 모두 준영속성 상태가 된다.
참고 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard 김영한 님의 JPA 프로그래밍 강의
https://book.naver.com/bookdb/book_detail.nhn?bid=9252528 자바 ORM 표준 JPA 프로그래밍
위의 책을 참고하고, 강의를 수강하면서 작성한 글입니다.
틀린 부분 등 다양한 피드백 환영합니다.
