[jpa] OSIV 성능 최적화

OSIV란

OSIV(Open Session In View)를 사용하면 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때까지 영속성 컨텍스트와DB 커넥션을 유지한다. 이렇게 함으로써 뷰와 컨트롤러에서 지연 로딩을 할 수 있다. 

 

*트랜잭션이 시작할때 DB커넥션을 획득한다.

 

하지만  이 전략은 큰 단점이 있는데,  너무 오랜 시간 DB 커넥션을 유지함으로 인해  리소스 부족 장애로 이어질 수 있다는 것이다.따라서 상황에 맞는 OSIV 전략이 필요하다.

 

OSIV 동작 방식

jpa에서는 OSIV의 기본값을 true (사용)으로 제공하고 있다.

 

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

2. 서비스 계층에서 미리 만들어둔 영속성 컨텍스트로 트랜잭션을 시작한다.(@Transactional 어노테이션이 있는 곳)

3. 트랜잭션을 커밋하면 영속성 컨텍스트를 플러시하지만 영속성 컨텍스트를 종료시키지는 않는다, (뷰, 컨트롤러까지 유지)

4. 요청이 돌아오면 플러시를 하지 않고 영속성 컨텍스트를 바로 종료한다.

 

OSIV OFF

OSIV를 끈 상태에서 트랜잭션이 끝나면 DB 커넥션을 반환하므로 리소스를 낭비하지 않는다.

하지만 영속성 컨텍스트도 종료시켜 버리기때문에 뷰와 컨트롤러에서 지연로딩을 할수없다.따라서 트랜잭션 내에서 모든 지연로딩을 처리해야한다.

 

이를 해결하기 위해서는 OSIV 를 다시 켠다거나 , 페치 조인을 사용하는 등 여러 방법이 있지만

가장 단순하게 관심사를 분리하는 것만으로 문제를 해결할 수 있다. (커맨드와 쿼리 분리)

 

커맨드와 쿼리 분리

보통 핵심 비즈니스로직은 한번 개발하면 쉽게 바뀌지 않는다.

반면 화면을 구성하는 뷰로직은 개발이 시작된 뒤에도 여러 번 바뀌므로 둘의 라이프 사이클이 다르다.

 

따라서 둘의 관심사를 명확하게 분리하는 것은 유지보수 관점에서 충분히 의미있다.

 

ex)

OrderService
OrderService: 핵심 비즈니스 로직
OrderQueryService: 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용)

 

두 서비스 모두 트랜잭션을 유지하면서 지연로딩을 사용할 수 있다.