OSIV 전략

Open Session In View : 하이버네이트

Open EntityManager In View : JPA

관례상 OSIV라 부른다.

 

spring.jpa.open-in-view : true (Default 값)

• OSIV ON

OSIV 전략은 트랜잭션 시작처럼 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때까지 영속성컨텍스트와 테이터 베이스 커넥션을 유지한다. → 즉, controller 단에서 지연로딩 사용이 가능하다, 지연로딩을 트랙잭션에 안에서 모두 처리하지 않아도 된다.

 

•  OSIV OFF

 

OSIV를 끄면 트랜잭션 종료시 영속성 컨텍스트가 종료되고 데이터베이스 커넥션 또한 반환된다. 따라서 리소스를 낭비하지 않는다. 영속성 컨텍스트가 종료될 시, 당연히 지연로딩 또한 사용할 수 없기 때문에 지연로딩에 대한 코드는 모두 트랜잭션 안에서 처리해야 한다.

 

 

OSIV 전략

장점 : 영속성 컨텍스트와 데이터베이스 커넥션이 API 응답시점까지 계속 유지되고 있기 때문에 지연로딩이 가능하다.

 

단점 : 너무 오랜시간동안 데이터베이스 커넥션 리소스를 사용하기 때문에 실시간 트래픽이 중요한 애플리케이션에서는 케녁션이 모자랄 수 있다. → 컨트롤러에서 외부 API를 호출하면(외부 api기 때문에 대기 시간이 비교적 길 수 있다.) 외부 api 대기시간 만큼 데이터베이스 커넥션 리소스를 반환하기 못하기 유지해야한다. → 즉, 데이터베이스 커넥션을 실제로 사용하지 않는데도 불구하고 데이터베이스를 반환하지 못한다. → controller 단 까지 커넥션을 끌고 가면 비효율적일 수 있다.

 

 

OSIV OFF 상태 - 복잡성 관리

1. 비즈니스 로직 코드 (Command)
2. 단순 api 화면을 위한 조회 코드(Query)

두개의 코드를 분리하여 관리한다.

controller 단의 지연로딩 코드들이 모두 service 단에서 처리되어 하기 때문에 service 단의 복잡성이 커질 수 있다.

규모가 작은 프로젝트에서는 두개 모두 한 곳에서 관리해도 상관없지만 규모가 커질수록 유지보수가 어렵기 때문에 이 둘의 관심사를 분리하는 선택은 유지보수 관점에서 의미있다.

또한 이 둘의 LifeCycle 이 다르다. 대부분 1.서비스 로직은 한 번 작성되면 비교적 변경이 적다. 하지만 2. api 화면 조회 코드는 프론트 화면이 빈번히 변경되기 때문에 이에 따라 조회코드 또한 변경되어야 하기 때문에 LifeCycle 이 비교적 짧다.

 

 

개인적 생각 - off 전략 선택

conroller 단에서 지연로딩을 사용할 일은 거의 없으며 쓰면 추가적인 디비 쿼리가 발생하기 때문에 성능상 좋지 않다.

때문에 조회쿼리 한번에 모든 api 화면에 필요한 정보들을 한 번에 조회할 수 있는 것이 베스트라 생각한다. 물론, toOne 모두 fetch.Lazy 전략을 디폴트로 가져가면서 조회 쿼리 작성시에 fetch 조인 또는 Join (left join, join)을 통해 조회하며 toMany의 컬렉션 엔티티 조회의 경우 @BatchSize 를 사용하는 것이 바람하다고 생각한다.

-비즈니스 로직과 조회 코드를 나누어 관리하는 것은 나누어 관리하는 비용보다 유지보수의 이점이 더 커질 경우 나누는 것을 고민해보록 하자.