JPA OSIV ( open-session-in-view )
OSIV ON
- JPA 는 트랜잭션 시작 시점에 맞춰 영속성 컨텍스트가 DB 커넥션을 가져온다. 그리고 OSIV 가 켜져있는 경우, 서비스 단의 트랜잭션이 끝나더라도 DB 커넥션을 반환하지 않는다. 이유는 컨트롤러 단에서 연관 관계에 있는 엔티티가 LAZY LOADING 이 일어나게 되고, 그로 인한 프록시 객체를 초기화하기 위해서이다. 따라서 영속성 컨텍스트는 DB 커넥션을 물고 살아있어야 한다.
- 그렇다면 언제까지 살아있을까? API 의 경우 응답이 유저에게 반환될 때 까지, 화면의 경우 뷰 템플릿이 렌더링될 때까지 살아있다.
- 그래서 지금까지 View Template 이나 API 컨트롤러에서 LAZY LOADING 이 가능했던 것이다.
- 하지만 치명적인 단점이 있다!
- 너무 오랫동안 DB 커넥션을 물고있기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 말라버릴 수 있다. 그리고 이 것은 장애로 이어진다.
- 예를 들어, 컨트롤러에서 외부 API 를 호출하면 외부 API 응답 대기 시간 만큼 커넥션 리소스를 반환하지 못하고, 유지해야 한다.
OSIV OFF
- OSIV 옵션을 off 한 경우, 트랜잭션이 끝나는 시점에 flush 및 commit 을 하고 영속성 컨텍스트를 날려버리고, DB 커넥션을 종료한다.
- 따라서 컨트롤러 단으로 객체가 넘어갔을 때, 영속성 컨텍스트 및 DB 커넥션을 사용하지 않는다.
- 따라서 트래픽이 많은 경우, 커넥션 리소스를 낭비하지 않게 된다.
- 하지만 치명적인 단점이 있다!
- 모든 LAZY LOADING 을 트랜잭션 안에서 처리해야 한다.
- 따라서 트랜잭션이 끝나기 전에 LAZY LOADING 을 모두 호출해두거나, fetch join 을 사용해야 한다.
커맨드와 쿼리의 분리 ( Command and Query Separation )
- 실무에서 OSIV 를 끈 상태로 복잡성을 관리하는 좋은 방법이다.
- 보통 비즈니스 로직은 특정 엔티티 몇게를 등록하거나 수정하는 것이므로 성능이 크게 문제가 되지 않는다.
- 그런데 복잡한 화면을 출력하기 위한 쿼리는 화면에 맞추어 성능을 최적화 하는 것이 중요하다.
- 하지만 그 복잡성에 비해 핵심 비즈니스에 큰 영향을 주는 것은 아니다.
- 그래서 크고 복잡한 애플리케이션을 개발한다면, 이 둘의 관심사를 명확하게 분리하는 선택은 유지보수 관점에서 충분히 의미 있다.
- 예를 들어, 아래와 같이 관심사를 분리한다면 두 서비스 모두 트랜잭션을 유지하면서 LAZY LOADING 을 사용할 수 있다.
- OrderService : 핵심 비지니스 로직
- OrderQueryService : 화면이나 API 에 맞춘 서비스 ( 주로 @Transactional(readOnly = true) )
결론
- 고객 서비스의 실시간 API 이거나 트래픽이 많은 경우 ( 성능 최적화가 요구되는 경우 ), OSIV 를 끄고 커맨드와 쿼리를 분리한다.
- ADMIN 과 같이 커넥션을 많이 사용하지 않는 곳에서는 OSIV 를 켠다.
REFERENCES
김영한님 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화