[JPA] Entity를 통해서 변경한 데이터를 DB는 어떻게 알아먹을까? → 영속성 관리

[JPA] Entity를 통해서 변경한 데이터를 DB는 어떻게 알아먹을까? → 영속성 관리

서버 코드 보고, QueryDsl 도 다루어 보면서 생긴 몇가지 궁금증을 해소해 주었던 지식을 기록

일단 궁금했던 점들

1. QueryDsl 을 작성할 줄 알고, 쓸 줄도 알겠어. 그런데 이 쿼리가 DB로 날라가는건 대체 어떤 시점이야?
2. → 이 시점을 근본적으로 이해할 정도의 구조적 지식이 필요했다.
3. 그 전에, JPA를 통해서 DB 테이블 정보를 바꿀 때는 member.setId(id) 이런 식으로 바꾼다. DB에 쿼리를 날린 것도 아니고, 트랜잭션을 따로 끝낸 적도 없는데 이게 어떻게 DB에 반영이 되는거야?
4. → Dirty Checking!

---

엔티티 매니저 팩토리와 엔티티 매니저

엔티티 매니저는 말 그대로 엔티티를 관리하는 애다. JPA 를 다루는 개발자 입장에서는 엔티티 매니저는 엔티티를 저장하는 가상의 데이터베이스라고 생각하면 된다. JPA로 쿼리를 작성하거나 QueryDsl을 사용 할 때, JPA 는 실제 데이터베이스가 아닌 엔티티 매니저에게 쿼리를 날린다.

엔티티 매니저 팩토리는 또한 이름 그대로 엔티티 매니저를 만드는 공장이다.

EntityManagerFactory factory = Persistence.createEntityManagerFactory("jpaBook")

이런 식으로 만들어서 사용하는데, 한번 생성할 때 비용이 매우 크므로 하나의 객체만 생성해서 어플리케이션 전체에서 공유하도록 설계 되어 있다.

즉, 엔티티 매니저 팩토리는 Atomicity 를 보장한다.

이는 엔티티 매니저와는 다른데, 엔티티 매니저는 여러 스레드가 동시에 접근 할 경우 하나의 데이터를 여러 군데에서 바꾸어 데이터의 무결성이 보장되지 않는다. 따라서 하나의 엔티티 매니저는 스레드간의 공유를 해서는 안된다.

---

영속성 컨텍스트 (Persistence Context)

영속성 컨텍스트는 엔티티를 영구 저장하는 환경이다. 이게 무슨 소린지 모르겠다. 당연하다. 왜냐하면 영속성 컨텍스트는 논리적인 개념에 가깝고 실제 눈에 보이지도 않는다.

그냥 엔티티 매니저가 생성될 때마다 하나씩 만들어지고, 엔티티 매니저가 엔티티를 저장하는 공간이라고 생각하자.

EntityManager em = factory.createEntityManager();
em.persist(member);

---

트랜잭션 일어나는 과정

transaction.begin();  //트랜잭션 시작
em.persist(memberA)  //멤버A, B를 영속성 컨텍스트에 등록
em.persist(memberB)

//이때까지 쓰기 지연에다가 쿼리들을 생성해서 넣어둠.
transaction.commit();  //flush()가 자동으로 실행되면서 트랜잭션이 커밋됨

이짓을 하는 이유

데이터 저장을 즉시 DB에 보내나 쓰기 지연에 넣어 놓고 나중에 한꺼번에 보내나, 둘 다 하나의 트랜잭션 안에서 일어난다면 결국 둘의 결과는 같을 것이다. 등록 쿼리가 불릴 때마다 매번 DB에 전달 하더라도 트랜잭션을 커밋하지 않으면 다 롤백 된다. 한 커밋 내에서 DB와 커넥션을 최소한으로 일으킨다면 부하를 줄일 수 있다.

---

Dirty Checking (변경 감지)

JPA는 엔티티를 영-컨에 보관할 때, 최초 상태를 복사해서 저장해두는데, 이것이 바로 스냅샷!

Flush() 가 실행될 때, 엔티티와 스냅샷을 비교해서 변경된 데이터가 있는지 확인하고, 변경 된 엔티티가 있으면 수정 쿼리를 생성해서 자동으로 쓰기지연 저장소에 저장한다.

---

데이터를 수정할 때 단순히 엔티티를 조회에서 데이터만 변경하고, em을 통해서 member를 매번 새롭게 등록할 필요가 없다.

단, 더티 체킹은 영속성 컨텍스트에 등록 된 엔티티에만 적용이 된다.

새로운 궁금증: 실제 프로젝트 코드에는 Entity Manager 라는 애는 나오지도 않는데 이건 뭐임?