영속성 컨텍스트

영속성 컨텍스트 (Persistence Context)

엔티티를 영구 저장하는 환경이다.
전에는 .persist() 메소드가 단순히 데이터를 저장한다고만 했었지만 사실은 엔티티를 영속성 컨텍스트 안에 저장한다.
이 영속성 컨텍스트는 엔티티 매니저를 생성할 때 만들어지며 엔티티 매니저를 통해서 접근, 관리 할 수 있다.

엔티티 매니저 (Entity Manager)
- 위에서 설명했던 대로 영속성 컨텍스트를 관리하기 위해서 생성한다.
- 엔티티 매니저 팩토리를 통해서 생성되며 생성 비용이 많이 들어가지 않는다.
- 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드간 공유는 안된다.
엔티티 매니저 팩토리 (Entity Manager Factory)
- 이름 그대로 엔티티 매니저를 만드는 공장이다.
- 생성 비용이 크기 때문에 보통 애플리케이션 전체에서 하나만 사용하게된다.
- 여러 스레드가 동시에 접근해도 안전하기에 스레드간 공유를 해도 상관없다.
위 처럼 엔티티가 생성되며 사용되는데, 엔티티의 생명주기는 다음과 같다.
- 비영속 (new/transient)
  - 영속성 컨텍스트와 전혀 관련이 없는 상태이다.
  - 엔티티 객체를 생성하고 저장하지 않았을 때, 다른 데이터베이스나 영속성 컨텍스트와 전혀 관련이 없을 때의 상태이다.
- 영속 (managed)
  - 엔티티 매니저를 통해서 영속성 컨텍스트에 저장한 상태이다.
  - 영속성 컨텍스트가 관리하고 있다는 뜻이라고 생각하면 편하다.
- 준영속 (detached)
  - 영속성 컨텍스트에 저장되었다가 분리된 상태이다.
  - 영속성 컨텍스트가 엔티티를 계속 관리하다가 관리하지 않게되면 엔티티는 준영속 상태라고 한다.
  - .detach()메서드가 호출되어 영속성 컨텍스트가 초기화되거나 .close()를 통해 영속성 컨텍스트가 닫히게 되면 준영속 상태가 된다.
- 삭제 (removed)
  - 삭제된 상태이다.
  - .remove()를 통해서 삭제를 하게된다.
  - 위 메서드를 호출하는 순간 영속성 컨텍스트에서 제거되기에 삭제된 엔티티는 재사용하지 말고 가비지 컬렉션의 대상이 되게 두는 것이 좋다.

영속성 컨텍스트의 특징

영속성 컨텍스트와 식별자 값
- 영속성 컨텍스트는 식별자 값 어노테이션(@Id, @Table)을 통해서 엔티티를 구분한다.
- 그러므로 영속 상태는 식별자 값이 반드시 있어야하며 없으면 예외가 일어난다.
영속성 컨텍스트와 데이터베이스 저장
영속성 컨텍스트를 통한 엔티티 관리
- 1차 캐시
  - 영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이를 1차 캐시라고 한다.
  - 우리가 알고 있는 캐시의 역할 처럼 이 1차 캐시또한 데이터를 저장하고 제공함으로써 성능상 이점을 누릴 수 있다.
  - EntityManager의 캐시 공간이라고 생각하면 된다.
```
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

em.persist("회원1"); // 엔티티 저장 = 1차 캐시에 저장
// 영속성 컨텍스트 안에 들어가게 되며 영속 상태가 되는 것

Member findMemeber = em.find(Member.class, "member1");
// 1차 캐시에서 조회하게 됨

Member findMemeber2 = em.find(Member.class, "member2");
// DB에서 조회하고, 1차 캐시에 저장하게 됨
```
  - em.find()를 호출 하면 먼저 메모리에 있는 1차 캐시에서 엔티티를 찾는다.
    - 만약 있다면 1차 캐시를 통해서 엔티티를 조회하게 된다.
    - 만약 없다면 DB를 통해서 조회하고 1차 캐시에 저장해두게 된다. (영속상태)
- 동일성 보장
  - 이전에 JPA를 소개할 때, DB에서 같은 값을 조회하였다고 해도 다른 객체라면 동일성이 보장되지 않는 패러다임을 설명했었다.
```
Member member1 = em.find(Member.class, "member1");
Member member2 = em.find(Member.class, "member1");

Sytem.out.println(member1 == member2); // 같은 주소 값 보장
```
  - 이 또한 영속성 컨텍스트를 통해서 해결이 되는 것이다.
  - 한 번 조회하고 난 이후에는 1차 캐시에 해당 엔티티가 저장되기 때문에, 이후에 조회할 때에도 같은 엔티티를 조회하며 동일성이 보장되게 된다.
- 트랜잭션을 지원하는 쓰기 지연
  - 이번에는 트랜잭션에 대한 쓰기 지연이다.
  - 먼저 트랜잭션(Transaction)이란, SQL의 실행 단위이다.
  - 저장하고, 삭제하고, 업데이트 하며 commit을 누를 떄 까지의 단위라고 생각하면 된다.
```
Entity Manager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

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

em.persist(memeber1);
em.persist(member2);
//얼핏 보기에는 DB에 바로 저장할 거 같지만 쿼리 저장소에 보관해두게된다.

transaction.commit(); // 트랜잭션 저장 (커밋)
```
  - em.persist();를 통해서 쿼리 저장소에 쿼리문들을 저장하게되고, transaction.commit(); 을 통해서 모아둔 쿼리를 DB에 보내게된다.
  - 위 같은 상황을 트랜잭션을 지원하는 쓰기 지연이라고 한다.
    - 트랜잭션을 커밋하게되면 엔티티 매니저는 우선 영속성 컨텍스트를 flush()하여 영속성 컨텍스트의 변경내용을 동기화한다.
    - SQL 쿼리들을 DB에 보내고 변경 내용을 데이터베이스의 변경내용을 동기화 한 후에 실제 DB 트랜잭션을 커밋하게 된다는 것이다.
  - 위에서는 Insert하는 것으로 예시를 들었지만 쓰기 지연은 Insert SQL 뿐만 아니라 Delete, Update에도 적용되는 사항이다.
  - 트랜잭션을 커밋하지 않으면 저장되지 않으며 롤백을 통해 되돌릴 수도 있으니 이와 같이 쓰기 지연이 가능해진다.
  - 이를 통해 성능 최적화등의 이점도 얻을 수 있다.
- 변경 감지
```
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

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

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

member1.setUsername("hi");
member.setAge(10); // 영속상태의 데이터 수정

// em.update()?

transaction.commit(); // 트랜잭션 커밋
```
  - JPA는 영속 상태의 엔티티를 변경하면 em.update();와 같은 코드가 없어도 변경사항을 감지하여 데이터베이스에 자동으로 반영하는 기능을 가지고 있다.
  - 이를 바로 변경감지라고 한다.
    - JPA는 엔티티를 영속성 컨텍스트에 보관할 때 최초 상태를 보관하게 되는데 이를 스냅샷이라고 한다.
    - commit() 을 사용하면 flush()를 통해서 스냅샷과 엔티티를 비교하게 되고, 변경된 엔티티를 찾아 업데이트를 진행하게 된다.
    - 그 후 진짜 커밋을 통해 변경내용을 저장한다.
  - 여기서 중요한점은 영속 상태의 엔티티여야만 한다는 점이다.
  - 만약 준영속이거나 삭제된 엔티티의 값을 변경하면 반영되지 않는 것을 볼 수 있다.
  - 이렇게 업데이트를 진행하게 되면 수정된 데이터에 대한 쿼리문이 작성될 것 같지만 예상 외로 그렇지않다.
```
UPDATE MEMBER
SET
	NAME = ?,
	AGE = ?,
	GRADE = ?,
	...
WHERE
	ID = ?;
```
  - 위와 같이 모든 필드를 사용해서 업데이트 문을 작성하게된다.
    - 모든 필드를 사용하면 수정쿼리가 항상 같아지게 때문에 수정쿼리를 미리 생성해두고 재사용 할 수 있다는 장점이 있다.
    - DB에 동일한 쿼리를 보내면 이전에 한 번 파싱된 쿼리를 재사용 할 수 있다.
  - 물론 필드가 많아지거나 저장되는 내용이 너무 커지게 되면 UPDATE 문을 동적으로 생성하는 것이 효율이 좋기에 그 때는 Hibernate의 동적 update를 사용하면 된다. @org.hibernate.annotations.DynamicUpdate
  - 참고로 INSERT 문도 존재하는 데이터 값만 골라서 동적으로 생성해주는 @DynamicInsert가 있다.
- 지연 로딩
  - 실제 객체 대신 프록시 객체를 로딩해두고 해당 객체를 실제 사용할 때 영속성 컨텍스트를 통해 데이터를 불러오는 방법이다.

플러시 (flush)

넘어가기 전에 플러시에 대해서 좀 더 자세히 살펴보자.
위에서 설명했던 것처럼 영속성 컨텍스트의 변경 내용을 DB에 반영하는 역할을 한다.
- 변경 감지가 동작하여 영속성 컨텍스트 안에 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 찾는다.
- 수정된 엔티티가 있다면 관련 쿼리를 SQL 저장소에 등록한다.
이런 플러시를 사용하는 방법은 3가지가 있다.
플러시 모드 옵션

준영속

위에서 비영속, 영속, 삭제에 대한 상태 변화는 살펴보았는데 준영속에 대해서는 살펴보지 않은 것 같아 이번에는 준영속에 대해서 정리해보겠다.
em.detach()
em.clear()

영속성 컨텍스트 (Persistence Context)

엔티티 매니저 (Entity Manager)

엔티티 매니저 팩토리 (Entity Manager Factory)

영속성 컨텍스트의 특징

플러시 (flush)

준영속