JPA 엔티티 매니저와 영속성 컨텍스트의 관계

1️⃣ 엔티티 매니저(EntityManager)란?

엔티티를 영속성 컨텍스트에 등록하거나 조회・수정・삭제 등 DB 작업을 수행하는 객체
생성은 EntityManagerFactory에서 이뤄지며, Spring에서는 트랜잭션 단위로 생성 소멸된다.
스프링 부트+Spring Data JPA 환경에서는 EntityManager를 직접 쓰지 않고, Repository를 통해 간접적으로 사용

2️⃣ 영속성 컨텍스트(Persistence Context)란?

JPA의 핵심적인 기능으로, 엔티티를 효율적으로 관리하고 객체와 데이터베이스 간의 패러다임 불일치를 해결하는 데 중요한 역할

[1] 1차 캐시
- 동일 트랜잭션 안에서 같은 PK 엔티티를 재조회 시 SELECT 쿼리 추가 실행되지 않는다 → 동일성이 보장된다.
[2] Dirty Checking(변경 감지)
- 엔티티 속성 변경을 추적, 트랜잭션 커밋 시점에 UPDATE SQL 자동 수행
[3] 지연 로딩(Lazy Loading)
- 연관관계가 설정된 엔티티를 실제 필요 시점에 DB로부터 가져옴
- OSIV - trade off
OSIV(Open Session In View)란?

OSIV는 HTTP 요청이 시작될 때부터 응답이 완료될 때까지 영속성 컨텍스트(EntityManager, 즉 Hibernate의 Session)를 열어 두는 전략

OSIV가 없으면? -> HTTP 요청 초반부인 Service Layer에서만 트랜잭션과 영속성 컨텍스트가 살아 있다. 따라서 Controller나 View에서 Lazy Loading을 시도하면 LazyInitializationException 발생 ⚠️

👉 실무에서는 어떻게 할까?
- OSIV 끄는 것을 권장하는 흐름이 많다 (spring.jpa.open-in-view=false)
- 지연 로딩을 쓰기 쉽지만, 트래픽이 많아질수록 DB 리소스를 오래 점유하는 것이 치명적일 수 있기 때문에, 규모가 있는 서비스에서는 대부분 OSIV를 비활성화하고 트랜잭션 내에서 필요한 데이터를 모두 조회하는 방식을 택한다
[4] 쓰기 지연(Write-behind)
- INSERT, UPDATE SQL을 (1차 캐시) 모아두었다가 커밋 시 일괄 처리 시도

3️⃣ 트랜잭션 관리

Propagation(전파 레벨)

트랜잭션 전파(Propagation)은 스프링에서 하나의 트랜잭션이 진행 중일 때, 다른 트랜잭션을 호출하면 어떻게 동작할지를 정의하는 것.

→ 즉, A 서비스 메서드가 트랜잭션을 갖고 있을 때, 내부에서 B 메서드(또는 다른 서비스)를 호출하면,

B는 A의 트랜잭션을 공유할지, 새로 만들지, 아니면 예외를 던질지를 설정하는 게 전파 속성(Propagation)이다.
```
@Transactional
public void outerMethod() {
    try {
        innerService.innerMethod(); // 별도 트랜잭션
    } catch (Exception e) {
        // outer는 rollback 안 함
    }
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void innerMethod() {
    // outer 트랜잭션과는 독립적
}
```
트랜잭션 전파 레벨

스프링에서 @Transactional로 선언적 트랜잭션을 쓸 때, propagation 옵션으로 전파 방식을 제어
- PROPAGATION_REQUIRED: 이미 트랜잭션이 있으면 참여, 없으면 새로 시작 -> 가장 흔한 케이스
- PROPAGATION_REQUIRES_NEW : 항상 새로운 트랜잭션 시작. 기존 트랜잭션이 있으면 일시 중단
- PROPAGATION_MANDATORY : 반드시 기존 트랜잭션에 참여. 없으면 예외 발생 (IllegalTransactionStateException)
- PROPAGATION_SUPPORTS : 기존 트랜잭션이 있으면 참여, 없으면 트랜잭션 없이 실행
- PROPAGATION_NOT_SUPPORTED : 트랜잭션 없이 실행. 기존 트랜잭션이 있으면 일시 중단
- PROPAGATION_NEVER : 트랜잭션 없이 실행. 기존 트랜잭션이 존재하면 예외 발생
- PROPAGATION_NESTED : 기존 트랜잭션 내에서 중첩 트랜잭션 생성 / 부모 트랜잭션에 종속적

4️⃣ N+1 문제

N+1 문제 정의

한 번의 조회로 주 엔티티 “N개”를 가져왔을 때, 각각의 연관 엔티티를 다시 조회하는 쿼리가 “N번” 추가 실행되어 총 (1 + N)번의 쿼리가 발생하는 현상

public void printTeamMembers(EntityManager em) {
    List<Team> teams = em.createQuery("SELECT t FROM Team t", Team.class)
                          .getResultList(); // 1️⃣ 1번 쿼리 (Team 전체 조회)

    for (Team team : teams) {
        System.out.println("Team: " + team.getName()); // 2️⃣ N(팀수)번 쿼리 발생
        for (Member member : team.getMembers()) {
            System.out.println("   Member: " + member.getUsername());
        }
    }
}

⬇️

for (Member member : team.getMembers()) {
    System.out.println("   Member: " + member.getUsername());
}
// 여기서 다음과 같은 쿼리 발생 SELECT * FROM member WHERE team_id = ?

👉 여기서 무슨 일이 벌어지냐면?

SELECT * FROM team → 팀 전체 조회 (1번)
각 팀마다 SELECT * FROM member WHERE team_id = ? 쿼리 발생 (팀 수 만큼 N번)
- 팀이 5개면 → 총 6번 쿼리 실행 (1 + 5)

JPA 엔티티 매니저와 영속성 컨텍스트의 관계

1️⃣ 엔티티 매니저(EntityManager)란?

2️⃣ 영속성 컨텍스트(Persistence Context)란?

[1] 1차 캐시

[2] Dirty Checking(변경 감지)

[3] 지연 로딩(Lazy Loading)

[4] 쓰기 지연(Write-behind)

3️⃣ 트랜잭션 관리

트랜잭션 전파 레벨

4️⃣ N+1 문제

N+1 문제 정의

N+1 문제 발생 원인