[JPA] 영속성 관리 - 내부 동작 방식

JPA에서 중요한 2가지

• 객체와 관계형 데이터베이스 매핑
• 영속성 컨텍스트

 

영속성 컨텍스트

---

엔티티를 영구 저장하는 환경

JPA가 엔티티의 생명주기를 관리하고, 데이터 변경사항을 추적하여 DB에 동기화하는 공간

• EntityManager.persist(entity); → 영속성 컨텍스트에 엔티티를 저장한다 뜻
• 영속성 컨텍스트는 논리적인 개념이며 눈에 보이지 않음
• 엔티티 매니저를 통해서 영속성 컨텍스트에 접근
• 엔티티 매니저 생성시 - 영속성 컨텍스트라는 눈에 보이지않는 공간이 생김(1:1, N:1)

 

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

• 웹 애플리케이션이 실행될 때 EntityManagerFactory 생성
• 요청 올 때마다 EntityManage 생성해, 커넥션 풀을 사용해서 DB에 접근

 

엔티티의 생명주기

---

• 비영속 (new/transient) : 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
• 영속 (managed) : 영속성 컨텍스트에 관리되는 상태
• 준영속 (detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태
• 삭제 (removed) : 삭제된 상태

✓ 비영속

JPA에 관계없이 그냥 객체 생성, 초기화만 된 상태

✓ 영속

• 엔티티 매니저를 통해 영속성 컨텍스트에 접근
• 영속 상태가 된다고 해서 바로 DB에 쿼리 날라가는 건 아님 → 이후에 커밋해야 저장됨

✓ 준영속, 삭제

• 준영속 : 영속성 컨텍스트에서 지움

 

영속성 컨텍스트의 이점

---

• 1차 캐시
• 동일성(identity) 보장
• 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)
• 변경 감지(Dirty Checking)
• 지연 로딩(Lazy Loading)

✓ 1차 캐시

저장

저장 구조 : Key(PK 값), Value(엔티티 객체)

 

조회

find시 DB를 뒤지는게 아니라 영속컨텍스트 1차캐시에서 찾아 반환

이때, 없으면 DB 조회

 

DB 조회

1차 캐시에 없으면 DB 조회(sql) 후 1차캐시에 저장, 반환

 

참고 : em 닫으면 1차 캐시도 같이 없어지기 때문에 한 트랜젝션에서만 이득
          전체공유는 2차 캐시

 

✓ 영속 엔티티 - 동일성 보장

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");

System.out.println(a == b); //동일성 비교 true

 

✓ 엔티티 등록 - 트랜잭션을 지원하는 쓰기 지연

EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();

tx.begin();//트랜잭션 시작(데이터 변경 이안에서)

em.persist(memberA);
em.persist(memberB);
//아직 SQL 디비에 보내지 않음

transaction.commit(); //커밋 순간 DB에 INSERT SQL보냄

 

• em.persist(memberA);로 memberA를 1차 캐시 넣음과 동시에 엔티티 분석해 SQL문 생성해 쓰기 지연 SQL 저장소에 쌓아둠
• em.persist(memberB);도 동일하게 진행후 쓰기 지연 SQL 저장소에 쌓아둠

tx.commit();하는 시점에 쓰기 지연 SQL 저장소에 쌓인 SQL문들이 한꺼번에 날아감.(Flush)

후에 트랜잭션 커밋

 

쓰기 지연을 사용하는 이유?
버퍼링 기능으로 인해 쿼리를 여러 번 날리지 않고 최적화가 가능하기 때문

 

✓ 엔티티 수정 - 변경 감지(Dirty Checking)

EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();

// 영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

// 영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);

//em.update(member) 해야하지않나 싶겠지만 쓰면안됨

tx.commit();

 

1. 커밋시 내부적으로 flush() 호출

2. 스냅샷(값들어온 최초상태 복사본)과 비교

3. 변경사항 있을 시, UPDATE SQL문 생성 저장소에 쌓아둠

4. flush

5. commit

 

✓ 엔티티 삭제

//삭제 대상 엔티티 조회
Member memberA = em.find(Member.class, “memberA");
						 
em.remove(memberA); //엔티티 삭제

 

이것도 커밋 시점에 나감

 

플러시(Flush)

---

영속성 컨텍스트의 변경 내용을 DB에 반영하는 것 (== 쓰기 지연 SQL 저장소의 쿼리들을 DB에 전송)

* flush()는 DB에 쿼리를 날릴 뿐, 커밋하지 않음

그래서, flush() 이후 롤백도 가능

• 영속성 컨텍스트를 비우지 않음
• 영속성 컨텍스트의 변경내용을 데이터베이스에 동기화
• 트랜잭션이라는 작업 단위가 중요 → 커밋 직전에만 동기화 하면 됨

 

✓ 플러시 발생 (commit() 시 flush 자동 호출)

1. 변경 감지(Dirty Checking) : 스냅샷과 비교

2. (있다면) 쓰기 지연 SQL 저장소에 변경 SQL문 등록 (등록, 수정, 삭제 쿼리) 조회SELECT❌

3. flush : 저장소에 쌓인 쿼리문 DB에 전송

 

✓ 영속성 컨텍스트를
 플러시하는 방법

• em.flush() - 직접 호출
• 트랜잭션 커밋 - 플러시 자동 호출
• JPQL 쿼리 실행 - 플러시 자동 호출

✓ JPQL 쿼리 실행시 플러시가 자동 으로 호출되는 이유

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);

//중간에 JPQL 실행
query = em.createQuery("select m from Member m", Member.class);
List<Member> members= query.getResultList();

아직 쿼리 날라가기전인데, JPQL실행되면 문제생겨서 이를 방지하고자 JPQL 쿼리 실행시 자동 호출되게 함

 

✓ 플러시 모드 옵션 

(쓸일없음..)

em.setFlushMode(FlushModeType.COMMIT)

• FlushModeType.AUTO : 커밋이나 쿼리를 실행할 때 플러시(기본 값)
• FlushModeType.COMMIT : 커밋할 때만 플러시

 

준영속 상태

---

• 영속 → 준영속
• 영속 상태의 엔티티가 영속성 컨텍스트에서 분리(detached)
• 영속성 컨텍스트가 제공하는 기능을 사용 못함

✓ 준영속 상태로 만드는 방법

• em.detach(entity) : 특정 엔티티만 준영속 상태로 전환
• em.clear() : 영속성 컨텍스트를 완전히 초기화
• em.close() : 영속성 컨텍스트를 종료