OSIV(Open Session In View) 옵션
OSIV(open session in view) 는 영속성 컨텍스트를 뷰까지 열어 둔다는 의미입니다. 영속성 컨텍스트가 살아있으면 엔티티는 영속 상태로 유지될 수 있어, 뷰에서도 지연 로딩을 사용할 수 있어요. OSIV의 핵심은 뷰에서도 지연 로딩이 가능하도록 하는 것입니다. 가장 단순한 구현은 클라이언트 요청이 들어올때 필터나 인터셉터에서 트랜잭션을 시작하는 방법인데요. 이를 트랜잭션 방식 OSIV라고 합니다. 하지만, 트랜잭션 방식 OSIV는 표현 계층에서도 엔티티를 수정할 수 있기 때문에 유지보수하기 어려운 코드를 만들 수 있습니다.
✔️ 트랜잭션 방식의 OSIV의 문제 해결 방법
최신 방식의 OSIV는 트랜잭션 방식의 문제를 해결합니다. 스프링 OSIV는 OSIV를 사용하면서 트랜잭션은 비즈니스 계층에서만 사용합니다. 표현 계층에서는 트랜잭션이 없기 때문에 수정이 불가능합니다. 하지만, 표현 계층에서 트랜잭션 없는 읽기를 이용해 지연 로딩은 가능합니다. 동작 원리는 다음과 같습니다.
- 클라이언트의 요청이 들어오면 서블릿 필터나 스프링 인터셉터에서 영속성 컨텍스트를 생성합니다.
- 응용 계층에서
@Transactional로 트랜잭션을 시작할 때 미리 생성한 영속성 컨텍스트를 찾아와서 트랜잭션을 시작합니다. - 응용 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시합니다. (영속성 컨텍스트는 종료하지 않습니다.)
- 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지할 수 있습니다.
- 필터, 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료하는데 이때 플러시는 수행하지 않습니다.
✔️ 스프링 방식의 OSIV의 문제점
- 표현 계층에서 엔티티를 수정하면 데이터베이스에 반영하지 않습니다. 하지만, 엔티티를 수정한 이후 트랜잭션을 시작하는 응용 계층을 시작한 경우 문제가 발생합니다. 응용 계층 트랜잭션이 끝나고 영속성 컨텍스트를 플러시하는 과정에서 변경 감지가 동작할 수 있습니다.
OSIV는 요청-응답 전 과정을 하나의 영속성 컨텍스트로 유지 → 표현 계층의 코드도 영속 상태 엔티티에 접근 가능.
JPA 변경 감지는 트랜잭션 시작 시점이 아니라 커밋 시점에 동작.
표현 계층에서의 변경이 “응용 계층 트랜잭션” 안에서 flush 타이밍에 함께 반영되어 버림.
이게 개발자가 의도하지 않은 데이터 변경으로 이어질 수 있음.
OSIV기능을 사용하면 상대적으로 오래 DB 커넥션을 점유하기 때문에 커넥션 고갈로 이어질 수 있습니다.
✔️ OSIV 기능 비활성화
OSIV 기능이 활성화되어 있는 경우에는 트랜잭션의 범위를 벗어나도 커넥션을 계속 유지합니다. 만약 트래픽을 많이 받는 상황이라면, 커넥션 고갈로 이어질 수 있습니다. OSIV 기능을 비활성화하여 데이터베이스 커넥션을 효율적으로 사용할 수 있습니다.
그러면 무조건 OSIV 기능을 비활성화해야 할까?
무조건 비활성화하기 보다는 꺼야하는 근거가 필요합니다. 만약 트랜잭션 범위 밖에서 지연로딩을 반드시 수행해야하는 경우에는 활성화해야 합니다.
데이터베이스를 복제하여 사용하는 경우, 데이터 소스도 분리해야 하는데, OSIV 기능으로 인해 예기치 않은 데이터베이스로 요청이 전달될 수 있습니다.
그리고, 대량의 트래픽이 발생하는 경우처럼 데이터베이스 커넥션을 효율적으로 사용해야할 수도 있습니다. 위와 같은 경우에는 OSIV 비활성화를 고려해볼 수 있습니다.