OSIV

결론부터 얘기하면 OSIV는 영속성 컨텍스트를 View까지 열어두는 기능이다.

• Springboot 에는 spring.jpa.open.in-view라는 옵션이 있다. (true/false)

• default는 true이다.

영속성 컨텍스트는 언제 생기고 언제 사라질까?

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

서비스의 트랜잭션이 시작되면서 영속성 컨텍스트가 만들어지고 엔티티는 영속 상태가 된다.

영속성 컨텍스트는 트랜잭션이 시작될 때 만들어지고 트랜잭션이 커밋된 후 사라진다.

서비스가 끝나고 트랜잭션에서 나오면 준영속 상태가 될 것이다.

• 영속성 컨텍스트는 사용자가 요청하는 시점에 생성되지만 데이터를 읽고 쓰는 DB 트랜잭션은 비즈니스 레이어에서만 사용되도록 트랜잭션이 발생한다.

그래서 OSIV가 뭐냐면 트랜잭션이 끝나도 영속성 컨텍스트와 DB 커넥션을 살려두는 것이다.

API의 경우에는 응답을 반환할 때까지, 화면의 경우 뷰 템플릿을 렌더링 할 때까지

결국, 유저에게 response 할 때까지 영속성 컨텍스트와 DB 커넥션이 계속 살아있는 것이다.

OSIV의 최대 장점은 컨트롤러나 뷰에서도 Entity를 Lazy 로딩해서 활용할 수 있다.

OSIV-false

OSIV=false

• 트랜잭션을 종료할 때 영속성 컨텍스트를 닫고 DB 커넥션을 반환한다.

  • 반환하고 나서 DB 커넥션을 사용하지 않는다.

• 모든 지연 로딩을 트랜잭션 안에서 해결해야 한다.

  • 지연 로딩을 하기 위해서는 영속성 컨텍스트가 살아있어야 한다.

  • 트랜잭션이 종료되기 전에 지연 로딩을 호출하거나 fetch join을 사용해야 한다.

예를 들어, User와 매핑된 Review가 존재한다. OSIV를 끄고 Controller에서 User로 Review를 가져오면 어떻게 될까?

could not initialize proxy 에러가 발생한다. 그 이유는 트랜잭션이 종료되고 영속성 컨텍스트가 존재하지 않기 때문에 프록시를 초기화 할 수 없다. Review를 Lazy Loading 하지만 User는 준영속 상태이기 때문이다.

@GetMapping()
public List<Review> reviews() {
  List<Review> allReview = reviewRepository.findALl();
  for (Review review : allReview) {
	review.getUser().getName();
	review.getComment();
  }
  return allReview;
}

OSIV를 끄고 위 API를 호출하면 review.getUser().getName() 에서 Could not initalize proxy no Session에러가 발생한다. getUser()는 프록시인데 아직 데이터가 존재하지 않는다. 그래서 getName()을 호출하는 순간 영속성 컨텍스트에서 프록시를 초기화해야 하는데 여기서 에러가 발생한다.

간단하게 해결하기 위해서는 fetch join을 사용하거나 트랜잭션 안에서 처리하면 되는데, 처음부터 설계를 잘 한다면 이 부분은 이미 신경쓰지 않아도 될 것이다. 다시 한번 설계가 중요한 이유를 알 것 같기도하다.

OSIV-true

OSIV=true

• 트랜잭션 밖에서도 영속성 컨텍스트가 존재하여 DB 커넥션을 유지하고 있다.

  • 즉, API 응답 후 화면이 렌더링 될 때까지 영속성 컨텍스트를 물고 있는다.

• DB 커넥션을 계속 물고 있기 때문에 실시간 트래픽이 중요한 서비스에서는 커넥션이 부족할 수 있다.

• Controller에서도 지연 로딩으로 데이터를 가져올 수 있다.

1. 요청이 들어오면 Servlet Filter나 Spring Interceptior에서 영속성 컨텍스트(Entity Manager)를 생성한다. ---> 영속성 컨텍스트를 생성한다고 트랜잭션이 시작되는 것은 아니다.

2. Service Layer에서 트랜잭션이 시작할 때 기존에 생성된 영속성 컨텍스트를 이용해서 트랜잭션을 시작한다.

3. Service 로직이 끝나면 트랜잭션을 커밋하고 종료한다. 하지만 영속성 컨텍스트는 소멸되지 않는다. ---> DB 커넥션이 아직 종료되지 않았다.

4. Controller와 View에서도 영속성 컨텍스트가 유지되기 때문에 사용된 Entity는 영속 상태를 유지한다.

5. Servlet Filter 혹은 Spring Interceptor로 로직이 다시 회귀된 경우, 영속성 컨텍스트를 종료한다. ---> 이 때, flush 메서드가 아닌 close를 호출한다.

3번 이후에는 Controller부터 Entity가 수정 불가능한 상태가 되는데, 이 때는 트랜잭션이 종료된 상태이다.

하지만 Entity를 수정/삭제 하는 작업이 아니라 조회는 아무런 상관이 없다.

따라서 Entity 객체를 렌더링하는 과정에서 지연 로딩이 발생해도 조회만 하기 때문에 Controller에서도 가능하다. ---> JPA를 사용해서 Entity를 수정/삭제하는 행위는 반드시 트랜잭션 범위에서 수행해야 한다.

영속성 컨텍스트는 변경 감지(Dirty Checking) 기능을 가지고 있어서 트랜잭션 밖에서 수정/삭제를 시도한다면 데이터가 수정되지 않는다.

• 영속성 컨텍스트의 변경 내용을 DB에 반영하려면 영속성 컨텍스트를 flush 해야하는데, Spring이 제공하는 OSIV 요청이 끝나면 flush를 호출하지 않고, close 메소드를 호출하므로 Entity의 변경을 DB에 반영하지 않고 종료함.

• 강제로 DI를 이용해서 Spring의 EntityManager를 사용해서 flush를 호출해도 이를 예외 처리로 막아버리는 코드 때문에 안됨.

OSIV를 언제 사용하면 좋을까?

OSIV를 사용하지 않는 경우

• 서비스의 트래픽이 많은 실시간 API

• Controller와 Service가 1:1 매핑인 경우

• Service에서 트랜잭션이 종료되는 경우

OSIV를 사용하는 경우

• View에서 Entity 객체를 사용해서 렌더링 해야하는 경우 (Spring MVC)

• View에서 Entity 연관 객체를 제어해야 하는 경우

• 같은 영속성 컨텍스트에서 여러 트랜잭션을 공유하는 경유

Spring MVC의 경우 Entity를 Service 계층 위까지 사용하거나 트랜잭션을 공유해서 사용하는 경우가 있다.

그런 경우가 아니라면 OSIV 사용은 DB 커넥션을 오래 사용하게 되어 성능에 영향을 줄 수 있다.