JPA Persistence Context

Overview

Persistence Context는 Entity를 managed 상태로 두고 동일성, 변경 감지, 쓰기 지연을 제공한다.

핵심 원리

flush는 관리 중인 상태 변화를 SQL로 동기화한다. Context가 너무 커지면 메모리와 Dirty Checking 비용이 증가한다.

stateDiagram-v2; [*] --> Transient; Transient --> Managed: persist; Managed --> Detached: clear; Managed --> DB: flush

실무에서 발생하는 문제

대량 처리에서 Entity를 계속 관리하면 1차 Cache와 변경 감지 Snapshot이 커져 Memory를 압박한다. Bulk DML 뒤에는 관리 상태가 DB와 어긋날 수 있다.

Trade-off

변경 감지는 Update 코드를 줄이고 Unit of Work를 제공하지만 관리 범위와 Flush 시점을 이해해야 한다. 명시적 SQL은 제어가 쉽지만 Mapping과 변경 추적을 직접 맡는다.

흔한 오해

1차 Cache는 Application 전체 Cache가 아니라 EntityManager 단위다. save()를 호출해야만 변경이 반영되는 것도 아니며 Managed Entity는 Flush 때 변경 감지된다.

Interview Questions

• 이 기술이 해결하는 핵심 문제는 무엇인가?
• 내부에서는 어떤 순서로 동작하는가?
• 운영 환경에서 어떤 지표와 실패 모드를 확인해야 하는가?

왜 필요한가

Transaction 안에서 같은 Identity의 Entity를 같은 객체로 유지하고 변경을 모아 DB에 반영한다. 조회 반복을 줄이는 것보다 동일성, 변경 감지, 쓰기 지연이 핵심이다.

내부 동작

Entity는 New, Managed, Detached, Removed 상태를 가진다. 조회한 Managed Entity의 Snapshot과 현재 값을 Flush 시 비교해 Update SQL을 만든다. Flush는 Commit 전이나 Query 실행 전에 발생할 수 있으며 Commit 자체와는 다르다.

Example

Transaction 안에서 조회한 회원의 이름을 바꾸면 별도 Update 호출 없이 Commit 시 SQL이 실행된다. 대량 Loop에서는 일정 단위로 flush와 clear를 호출해 관리 객체를 비우고 JDBC Batch 설정을 함께 검토한다.

Production Considerations

Transaction 범위를 짧게 유지하고 Flush 시점의 SQL을 Log/APM으로 확인한다. Bulk Update 뒤에는 clear 또는 재조회로 Stale Entity 사용을 막는다. Entity를 Web 계층까지 노출하지 않고 DTO 경계를 둔다.

Related Topics

N+1, Fetch Join, OSIV와 생명주기 경계를 함께 본다.