OSIV 옵션에 대해서 설명해주세요.

[le2sky]

뭘까용?

[GIVEN53]

em과 연관지어서 함께 이야기하면 좋을 듯 합니돠~~

[J-I-H-O]

<개요>
OSIV(Open Session In View)는 영속성 컨텍스트를 뷰 까지 열어두는 기능입니다. 뷰 까지 영속성 컨텍스트가 살아있다면 뷰에서도 지연 로딩을 사용할 수 있습니다.

<동작 원리>

영속성 컨텍스트는 API 요청 시점에 생성이 되지만, 데이터를 쓰거나 수정할 수 있는 트랜잭션은 비즈니스 계층에서만 사용할 수 있도록 트랜잭션이 일어납니다.

스프링 부트에서 spring.jpa.open-in-view 의 기본값은 true로, OSIV가 적용된 상태로 애플리케이션이 구성됩니다.
동작 원리는 다음과 같습니다.

1. 클라이언트의 요청이 들어오면 서블릿 필터나 인터셉터에서 영속성 컨텍스트를 생성합니다.

2. 서비스 계층에서 @Transactional 로 트랜잭션을 시작할 때, (1)번에서 미리 생성해둔 영속성 컨텍스트를 찾아와 트랜잭션을 시작합니다.

3. 서비스 로직이 끝나면 트랜잭션을 커밋하고, 영속성 컨텍스트를 플러시 합니다. 이 시점에 트랜잭션은 종료되지만, 영속성 컨텍스트는 종료되지 않습니다.

4. 컨트롤러와 뷰 까지 영속성 컨텍스트가 유지되므로, 조회한 엔티티는 영속 상태를 유지합니다. 하지만 이 때 트랜잭션 범위를 벗어났으므로, 조회는 가능하지만 수정 및 삭제는 불가능 합니다.
   (OSIV의 부작용으로 가능할 수 있음. 뒤에서 설명)

5. 서블릿 필터나 스프링 인터셉터로 응답이 돌아오면 영속성 컨텍스트를 종료합니다. 이 때 플러시를 호출하지 않고 바로 종료합니다.

   단순히 조회만 할 때에는 트랜잭션이 없어도 동작하는데, 이를 트랜잭션 없이 읽기(Nontransactional reads)라고 합니다.
   뷰 렌더링 과정 중에도 영속성 컨텍스트가 유지되므로 지연 로딩이 가능합니다.

   트랜잭션 범위 밖인 컨트롤러와 뷰에서 영속성 컨텍스트의 변경 감지에 의한 데이터 수정이 불가능한 이유는 다음과 같습니다.

   영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하려면 영속성 컨텍스트를 플러시 해야합니다. 스프링이 제공하는 OSIV 서블릿 필터나 OSIV 스프링 인터셉터는 요청이 끝나면 플러시를 호출 하지 않고, em.close() 로 영속성 컨텍스트를 종료합니다.

   뷰 영역에서 em.flush() 를 호출해 강제로 플러시하려 시도해도, 트랜잭션 범위 밖이므로 데이터를 수정할 수 없다는 예외가 발생합니다. (javax.persistence.TransactionRequiredException)

<OSIV 사용 시 주의점>

OSIV 전략은 트랜잭션 시작과 같이 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때 까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지합니다. 즉, 영속성 컨텍스트가 종료될 때 까지 데이터 베이스 커넥션을 1:1 로 계속 물고 있습니다.

이러한 특징으로 인해 프레젠테이션 계층에서 지연로딩을 사용할 수 있다는 장점이 있지만, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자라 장애로 이어질 수 있습니다.

또한 OSIV를 적용하면 API 요청 시점에 영속성 컨텍스트가 생성되므로, 같은 영속성 컨텍스트를 여러 트랜잭션이 공유하게 될 수 있기 때문에 주의해야 합니다.
잘못 사용하게 된다면 데이터가 변조될 수 있습니다.

@GetMapping
public Person get() {
    Person person = personService.get(1);
    person.setName("steve"); // presentation layer에서 이름 정보 변경
    Person person2 = personService.get(1);
    return person;
}

personService.get() 메서드는 @Transactional 로 감싸져 있어 메서드 종료 시 자동으로 em.flush() 를 호출합니다. 이때 변경 감지가 동작하여 변경된 내용을 데이터베이스에 반영하게 됩니다.

컨트롤러에서 이름 정보를 변경한 다음에 호출된 personService.get() 이 종료될 때, 엔티티 스냅샷과 flush 시점의 엔티티 데이터가 일치하지 않아 변경 감지가 동작하고, 변경 내용이 데이터베이스에 반영됩니다.

즉, OISV로 인해 영속성 컨텍스트가 여러 트랜잭션에 공유되었고, 뷰 영역에서 변조된 정보가 의도치 않게 데이터베이스에 반영될 수 있습니다.

OSIV를 끄면 트랜잭션을 종료할 때 영속성 컨텍스트를 닫고, 데이터베이스 커넥션도 반환합니다.
하지만 프레젠테이션 레이어에서 영속성 컨텍스트의 기능을 사용할 수 없기 때문에 트랜잭션 범위 내에서 모든 지연 로딩을 끝마쳐야 합니다.

https://incheol-jung.gitbook.io/docs/q-and-a/spring/osiv
https://ykh6242.tistory.com/entry/JPA-OSIVOpen-Session-In-View%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

[J-I-H-O]

TODO: 세줄 요약

[le2sky]

OSIV(open session in view)는 영속성 컨텍스트를 뷰까지 열어둔다는 뜻입니다.
영속성 컨텍스트가 살아있으면 엔티티는 영속 상태로 유지될 수 있어, 뷰에서도 지연 로딩을 사용할 수 있습니다.

[요청당 트랜잭션 방식 OSIV]
OSIV의 핵심은 뷰에서도 지연 로딩이 가능하도록 하는 것입니다.
가장 단순한 구현은 클라이언트 요청이 들어올때 필터나 인터셉터에서 트랜잭션을 시작하는 방법인데요.
이를 트랜잭션 방식 OSIV라고 합니다.
하지만, 이런 방식은 컨트롤러나 뷰 같은 표현 계층에서도 엔티티를 수정할 수 있다는 것이 단점입니다.
이는 유지보수에 어려운 코드를 만들 수 있습니다.

[스프링 OSIV]
위와 같은 문제로 인해서 최근에는 트랜잭션 방식 OSIV를 거의 사용하지 않습니다.
최신 방식의 OSIV는 트랜잭션 방식의 문제를 어느 정도 해결합니다.
이는 응용 계층에서 트랜잭션을 사용하는 OSIV입니다.
즉, OSIV를 사용하면서 트랜잭션은 비즈니스 계층에서만 사용합니다.

동작 원리는 다음과 같습니다.

• 클라이언트의 요청이 들어오면 서블릿 필터나 스프링 인터셉터에서 영속성 컨텍스트를 생성합니다. (트랜잭션은 시작하지 않습니다.)
• 응용 계층에서 @Transactional로 트랜잭션을 시작할 때 미리 생성한 영속성 컨텍스트를 찾아와서 트랜잭션을 시작합니다.
• 응용 계층이 끝나면 트랜잭션을 커밋하고, 영속성 컨텍스트를 플러시합니다. (트랜잭션은 종료하고, 영속성 컨텍스트는 종료하지 않습니다.)
• 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지할 수 있습니다.
• 필터, 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료하는데, 이때 플러시는 수행하지 않습니다.

정리하자면 스프링 OSIV는 다음과 같은 특징이 있습니다.

• 영속성 컨텍스트를 표현 계층까지 유지합니다.
• 표현 계층에는 트랜잭션이 없으므로 수정이 불가능합니다. (DB 반영 불가)
• 표현 계층에서는 트랜잭션 없이 읽기를 이용해 지연 로딩이 가능합니다.

스프링 OSIV는 다음과 같은 주의 사항이 있습니다. (영속성 컨텍스트를 여러 트랜잭션이 공유해서 발생하는 문제)

• 표현에서 엔티티를 수정한 경우 데이터 베이스에 반영하지는 않지만..
• 엔티티를 수정한 이후 트랜잭션을 시작하는 응용 계층을 시작할 경우 문제가 발생한다.
• 응용 계층 트랜잭션이 끝나면 커밋하고, 영속성 컨텍스트를 플러시하게 되는데, 이떄 변경 감지가 동작하여 수정이 반영될 수 있습니다.

[le2sky]

위에서 언급한 필터나 인터셉터(OpenSessionInViewFilter, OpernSessionInViewInterceptor, OpenEntityMangerInViewFilter, OpenEntityManagerInViewInterceptor)는 스프링 프레임워크에서 제공하는 OSIV 라이브러리에서 제공합니다.

웹으로부터 요청이 들어오면 등록된 OSIV 인터셉터의 preHandle에서
EntityManagerFactory로부터 em을 생성하여 현재 요청 스레드에 등록합니다. (em을 EntityManagerHolder로 감쌈)
이때 TransactionSyncronizationManager를 이용합니다.

응용 계층에서 트랜잭션이 시작되면 JpaTransactionManager에서 TransactionSyncronizationManager을 이용해
현재 스레드에 등록된 em을 조회합니다. 만약 em이 존재하면 트랜잭션 객체(JpaTransactionObject)에
기존 em을 바인딩합니다.

이때 이미 em이 존재하기 때문에 트랜잭션 객체의 setEntityManagerHolder 메서드 두번째 파라미터인 newEntityManagerHolder는 false가 됩니다. 해당 값은 em의 라이프 사이클을 결정하는 값으로 트랜잭션 커밋 이후 JpaTransactionManager가 em을 죽일지 말지 판단하는데 사용됩니다.

출처: https://brunch.co.kr/@anonymdevoo/58
출처: 그 책