[JPA] 13장. 웹 애플리케이션과 영속성 관리

[tonykang22]

13장. 웹 애플리케이션과 영속성 관리

트랜잭션 범위의 영속성 컨텍스트

스프링 컨테이너의 기본 전략

• 스프링 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 기본으로 사용한다.
  • 트랜잭션 범위 = 영속성 컨텍스트의 생존 범위
  • 트랜잭션 시작할 때 영속성 컨텍스트 생성하고, 트랜잭션 끝날 때 영속성 컨텍스트를 종료한다.
  • 같은 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근한다.

• @Transactional 애노테이션을 사용하면 스프링의 트랜잭션 AOP가 대상 메소드보다 먼저 동작한다.
  • 대상 메소드를 호출하기 직전에 트랜잭션을 시작하고, 대상 메소드가 정상 종료되면 트랜잭션을 커밋하면서 종료한다.

• 트랜잭션이 같으면 같은 영속성 컨텍스트를 사용한다.
  • 트랜잭션 범위의 영속성 컨텍스트 전략은 다양한 위치에서 엔티티 매니저를 주입받아 사용하더라도 결국 같은 트랜잭션이라면 항상 같은 영속성 컨텍스트를 사용하게 된다.

• 트랜잭션이 다르면 다른 영속성 컨텍스트를 사용한다.
  • 멀티 스레드 환경에서 동시 요청이 들어와 같은 엔티티 매니저를 사용해도 트랜잭션에 따라 접근하는 영속성 컨텍스트는 다르다.

• 트랜잭션은 보통 서비스 계층에서 시작하기 때문에 서비스 계층이 끝나는 시점에 트랜잭션이 종료되면서 영속성 컨텍스트도 함께 종료된다.
  • 조회한 엔티티가 서비스와 리포지토리 계층에서는 영속성 컨텍스트에 관리되면서 영속 상태를 유지하지만, 컨트롤러나 뷰 같은 프리젠테이션 계층에서는 준영속 상태가 된다.
  • 변경 감지 및 지연 로딩이 동작하지 않는다.
  • 지연 로딩 시점에 예외가 발생하게 된다.
  • 변경 감지 기능은 프리젠테이션 계층에서도 동작한다면 애플리케이션 계층이 가지고 있는 책임이 모호해지며, 유지보수 또한 어렵게 된다.
• 준영속 상태는 지연 로딩 기능이 동작하지 않는 점이 문제가 될 수 있다.
  • 예) 뷰를 랜더링할 때 연관된 엔티티도 함께 사용해야 하는데, 연관된 엔티티가 지연 로딩으로 설정되어 프록시 객체를 조회한 경우
  • 아직 초기화하지 않은 프록시 객체를 사용하면 실제 데이터를 불러오려고 초기화 시도
  • Hibernate 구현체를 사용했다면 LazyInitializationException 예외가 발생할 것이다.
• 해당 문제를 해결하는 방법은 크게 2 가지가 있다.
  • 뷰가 필요한 엔티티를 미리 로딩해두는 방법
  • 글로벌 페치 전략 수정
  • JPQL 페치 조인
  • 강제로 초기화
  • OSIV를 사용해 엔티티를 항상 영속 상태로 유지하는 방법

글로벌 페치 전략 수정

• 지연 로딩을 즉시 로딩으로 변경 (FetchType.EAGER)
• 단점 2 가지
  • 사용하지 않는 엔티티를 로딩한다.
  • 불필요한 정보까지 조회하게 될 수 있다.
  • N+1 문제가 발생한다.
  • JPA가 JPQL을 분석해서 SQL을 생성할 때는 글로벌 페치 전략을 참고하지 않고 오직 JPQL 자체만 사용한다.
  • 연관된 엔티티를 영속성 컨텍스트에서 찾지 못하게 되면 추가 SQL을 조회한 엔티티의 수 만큼 실행하게 된다.

JPQL 페치 조인

• 글로벌 페치 전략을 즉시 로딩으로 변경하는 것은 말그대로 애플리케이션 전체에 영향을 주기 때문에 비효율적이다.
• JPQL 페치 조인을 사용하면 SQL JOIN을 사용해 페치 조인 대상까지 함께 조회한다.
  • N+1 문제가 발생하지 않는다.
  • 화면에 필요한 엔티티를 미리 로딩하는 현실적인 방법이다.
• 단점
  • 현실적인 대안이지만, 무분별한 사용으로 인해 리포지토리 메스드가 증가할 수 있다.
  • 알게 모르게 프리젠테이션 계층이 데이터 접근 계층을 침범하게 되는 것이다.

강제로 초기화

• 영속성 컨텍스트가 살아있을 때 프리젠테이션 계층이 필요한 엔티티를 강제로 초기화해서 반환하는 방법이다.
  • 프리젠테이션 계층에서 필요한 프록시 객체를 영속성 컨텍스트가 살아 있을 때 강제로 초기화해 반환하면 이미 초기화되었기 때문에 준영속 상태에서도 사용할 수 있다.
  • Hibernate를 사용하면 initialize() 메소드를 사용해 프록시를 강제로 초기화할 수 있다.
• 단점
  • 뷰가 필요한 엔티티에 따라 서비스 계층의 로직을 변경해야 한다.
  • 서비스 계층에서 프리젠테이션 계층을 위한 프록시 초기화 역할을 분리해야 한다.
    • FACADE 계층이 그 역할을 담당해준다.

FACADE 계층

• 프리젠테이션 계층과 도메인 모델 계층 간의 논리적 의존성을 분리해준다.
• 프리젠테이션 계층에서 필요한 프록시 객체를 초기화한다.
• 서비스 계층을 호출해서 비즈니스 로직을 실행한다.
• 리포지토리를 직접 호출해서 뷰가 요구하는 엔티티를 찾는다.

OSIV

• OSIV(Open Session in View)는 영속성 컨텍스트를 뷰까지 열어둔다는 뜻이다.
  • 영속성 컨텍스트가 살아있다면 엔티티는 영속 상태로 유지된다.
  • 뷰에서도 지연 로딩을 사용할 수 있다.
  • OSIV는 Hibernate에서 사용하는 용어로, JPA에서는 OEIV(Open EntityManager in View)라고 하지만 관례상 OSIV라 부른다.

과거 OSIV: 요청 당 트랜잭션

• 가장 단순한 구현 방법은 클라이언트의 요청이 들어오자마자 서블릿 필터나 스프링 인터셉터에서 트랜잭션을 시작하고 요청이 끝날 때 트랜잭션도 끝나는 것이다.
  • 조회한 엔티티도 요청이 들어와 요청이 끝나는 시점까지 영속 상태를 유지하게 된다.
  • 이것을 요청 당 트랜잭션 방식의 OSIV라 한다.
  • FACADE 계층 없이도 뷰에 독립적인 서비스 계층을 유지할 수 있다.
• 문제점
  • 컨트롤러나 뷰 같은 프리젠테이션 계층이 엔티티를 변경할 수 있다는 점이 문제이다.
  • 엔티티를 수정하지 못하게 막는 방법들은 다음과 같다.
    • 엔티티를 읽기 전용 인터페이스로 제공
    • 엔티티 래핑
    • DTO만 반환
  • 모두 코드량이 상당히 증가한다는 단점이 있다.

엔티티를 읽기 전용 인터페이스로 제공

• 엔티티를 직접 노출하지 않고 읽기 전용 메소드만 제공하는 인터페이스를 프리젠테이션 계층에 제공하는 방법이다.

엔티티 래핑

• 위와 유사하게, 엔티티를 감싸는 엔티티Wrapper 객체를 만들어 읽기 메소드만 제공한다.

DTO만 반환

• 가장 전통적인 방법으로, 엔티티 대신에 DTO를 생성해 반환하는 방법이다.
  • 하지만 해당 방법은 OSIV를 사용하는 장점을 살릴 수 없고 엔티티를 복사한 듯한 DTO 클래스도 하나 더 만들어야 한다.

스프링 OSIV: 비즈니스 계층 트랜잭션

스프링 OSIV 분석

• 클라이언트의 요청이 들어오면 영속성 컨텍스트를 생성한다.
  • 이때 트랜잭션을 시작하는 것은 아니다.
• 서비스 계층에서 트랜잭션을 시작하면 앞서 생성한 영속성 컨텍스트에 트랜잭션을 시작한다.
• 비즈니스 로직 실행을 마치고 서비스 계층이 끝나면 트랜잭션을 커밋하면서 영속성 컨텍스트를 플러시한다.
• 이때 트랜잭션만 종료하고 영속성 컨텍스트는 살려둔다.
• 이후 클라이언트의 요청이 끝날 때 영속성 컨텍스트를 종료한다.

트랜잭션 없이 읽기

• 영속성 컨텍스트를 통한 모든 변경은 트랜잭션 안에서 이루어져야 한다.
  • 트랜잭션 없이 엔티티 변경 및 영속성 컨텍스트 플러시하면 TransactionRequiredException이 발생하게 된다.
  • 단순 조회 시에는 트랜잭션 없이 읽기가 가능하다.
• 스프링 OSIV를 사용하면 프리젠테이션 계층에서는 트랜잭션이 없어 엔티티를 수정할 수 없게 된다.
  • 기존의 OSIV 단점을 보완
  • 트랜잭션 없이 읽기를 사용해 프리젠테이션 계층에서 지연 로딩 기능 사용이 가능하다.

스프링 OSIV 주의 사항

• 프리젠테이션 계층에서 엔티티를 수정한 직후에 트랜잭션을 시작하는 서비스 계층을 호출하면 문제가 발생할 수 있다.
  • 해결 방안: 트랜잭션이 있는 비즈니스 로직을 모두 호출하고 나서 엔티티를 변경한다.
  • 스프링 OSIV는 같은 영속성 컨텍스트를 여러 트랜잭션이 공유할 수 있으므로 이런 문제가 발생한다.
  • OSIV를 사용하지 않는 트랜잭션 범위의 영속성 컨텍스트 전략은 트랜잭션의 생명주기와 영속성 컨텍스트의 생명주기가 같아 이런 문제가 발생하지 않는다.