- OSIV 단점
- 안쓰면 어떻게 하란 말인가?
OSIV 단점
(강의자료 그대로 발췌)
이 기본값을 뿌리면서 애플리케이션 시작 시점에 warn 로그를 남기는 것은 이유가 있다. OSIV 전략은 트랜잭션 시작처럼 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때 까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지한다. 그래서 지금까지 View Template이나 API 컨트롤러에서 지연 로딩이 가능했던 것이다. 지연 로딩은 영속성 컨텍스트가 살아있어야 가능하고, 영속성 컨텍스트는 기본적으로 데이터베이스 커넥션을 유지한다. 이것 자체가 큰 장점이다.
그런데 이 전략은 너무 오랜시간동안 데이터베이스 커넥션 리소스를 사용하기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있다. 이것은 결국 장애로 이어진다. 예를 들어서 컨트롤러에서 외부 API를 호출하면 외부 API 대기 시간 만큼 커넥션 리소스를 반환하지 못하고, 유지해야 한다.
OSIV true 인 상태에서 커넥션 및 영속성 컨텍스트 유지 시작 시점은 데이터베이스 커넥션 시작시점이고 종료 시점은 API 응답 시점
트래픽이 아주 많다고 했을때, OSIV를 켠 것과 끈 것을 비교한다면 킨 상태에서는 응답까지 계속 커넥션을 물고 있는 것이고 끈 상태에는 로직 처리시 필요한 시점만큼씩만 물고 있는 것. 어떻게든 커넥션을 물고있는 절대시간이 줄어드는 것이니까 성능상 이점은 맞다.
안쓰면 어떻게 하란 말인가?
강의에서 추천하는 것은 OSIV를 false 로 해두고 서비스를 따로 분리해서 응답을 위한 DTO로의 변환을 트랜잭션 내에서 처리하라는 것이다. 즉, OSIV를 켜두면 프레젠테이션 레이어에서 Response 를 위한 변환 작업을 거치면서 지연로딩 등이 발생되는데(나의 경우는 그렇다), 이를 서비스 내에서 다 처리하도록 하되 그걸 담당하는 서비스는 따로 두라는 것이다.
강의에서 예시로 든 것은 아래와 같다.
- OrderService: 핵심 비즈니스 로직
- OrderQueryService: 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용)
OrderService -> OrderQueryService 로의 의존을 갖고 OrderService에서 필요한 경우 OrderQueryService를 호출해서 OrderQueryService 내에서 지연로딩이 발생되도록 해서 필요한 DTO로의 변환을 처리하도록 하라는 것이다.
이건 JPA 기본 강의 및 도서 보면서 OSIV 쓰지 않을때 어떻게 처리할지(FACADE 패턴 등)에 관해서 따로 정리를 할 필요성이 있을 것 같다. 일단 기본 강의 들을때 정리해둔 부분을 링크를 남긴다. 나중에 FACADE 계층을 넣으면 샘플 코드를 다시 추가로 포스팅에 남겨야겠다.