영속성 컨텍스트

멘토님께서

https://medium.com/@ali75mnf/quick-journey-into-persistence-understanding-jpa-entity-lifecycle-d4333985a25d

Quick Journey into Persistence: Understanding JPA Entity Lifecycle

 

• 위 그림이 중요하다고 해주셨다

엔티티의 4가지 상태

1. New(=Transient 비영속)

• new로 막 생성한 순수 자바 객체
• 영속성 컨텍스트(1차 캐시)에 등록되지 않음 → 변경 추적 X, DB와 무관
• 전이
  • em.persist(e) → Managed 진입
  • em.merge(e) → (그대로는 비영속 유지, 새 Managed 복제본을 반환)
  • em.remove(e) → IllegalArgumentException(관리 대상이 아니므로)

2. Managed(= Persistent, 영속)

• 영속성 컨텍스트에 등록된 상태 (1차 캐시가 가지고 있음)
• Dirty Checking: 필드 값을 바꾸면 커밋/flush 시 UPDATE 자동 생성
• 동일성 보장: 같은 트랜잭션 내 동일 PK는 동일 객체
• 전이
  • em.remove(e) → Removed(삭제 예약)
  • em.detach(e) 또는 em.clear()/em.close() → Detached
  • flush/commit → DB와 동기화(INSERT/UPDATE/DELETE 실행)
  • em.refresh(e) → DB 값으로 다시 덮어씀

3. Removed(삭제 예약)

• em.remove(e)를 호출해 삭제가 예약된 Managed
• flush/commit 시 DELETE 실행
• 전이
  • (커밋 전이라면) em.persist(e) → 삭제 취소하고 다시 Managed (구현체/시점에 따라 다를 수 있어, 일반적으로 “커밋 전에만 가능”으로 이해하면 안전)
  • em.detach(e) → Detached (DB 삭제 전이면 단순 분리, 삭제는 취소되지 않음)

4. Detached(준영속)

• 한때 Managed였지만 컨텍스트에서 분리
• 변경 추적 X, UPDATE도 발생하지 않음
• 전이
  • em.merge(e) → 새 Managed 인스턴스 반환(반환된 객체를 사용! 원본은 여전히 Detached)
  • em.persist(e) / em.remove(e) → IllegalArgumentException(관리 대상 아님)

그림의 오른쪽 Database는 flush/commit 때 실제 SQL이 나가 동기화되는 지점을 뜻함.

 

화살표(전이) 하나씩 보기

• new → (persist) → managed
  • “등록”한다는 뜻. INSERT는 보통 커밋/flush 때 실행
• managed → (find/query)
  • 조회는 원래 Managed를 반환(이미 1차 캐시에 있으면 DB를 안 치고 반환)
• managed → (remove) → removed → (flush/commit) → DB에서 삭제
  • 삭제 예약 후 커밋 시 실제 DELETE
• managed → (clear/close/detach) → detached
  • 컨텍스트에서 분리 → 더 이상 변경 추적 X
• removed → (persist) → managed
  • (커밋 전) 삭제 예약 취소. 커밋되어 실제 삭제된 뒤엔 복원 개념이 아니라 “새로 저장”이 됩니다.
• detached → (merge) → managed
  • 병합 결과로 새 Managed가 생성/반환(원본은 계속 detached)