OSIV는 Open Session In View이고 Open EntityManager In View는 JPA에서 정확하지만 규칙에 따라 OSIV라고 합니다.
OSIV A
spring.jpa.open-in-view: true # 기본값
OSIV 전략은 거래 시작따라서 지속성 컨텍스트와 데이터베이스 연결은 초기 데이터베이스 연결(서비스 계층) 시작부터 API 응답(컨트롤러 계층)이 끝날 때까지(응답이 사용자에게 전송될 때까지) 유지됩니다. 템플릿 보기 또는 지연 로딩이 가능합니다.
지연 로딩은 지속성 컨텍스트가 활성 상태이고 지속성 컨텍스트가 항상 데이터베이스 연결을 유지하는 경우에만 가능합니다.
이것은 큰 장점입니다.
하지만 이 전략은 데이터베이스 연결 리소스를 너무 오래 사용따라서 실시간 트래픽이 중요한 애플리케이션에서는 연결 부족으로 서비스 중단이 발생할 수 있습니다. 예를 들어 컨트롤러에서 외부 API를 호출하면 연결 리소스가 반환되지 않고 외부 API의 대기 시간 동안 유지됩니다.
OSIV 꺼짐
spring.jpa.open-in-view: false
OSIV 전략을 비활성화하면 트랜잭션이 종료될 때 지속성 컨텍스트가 닫히고 데이터베이스 연결도 반환됩니다. 따라서 연결 리소스가 낭비되지 않습니다. OSIV가 꺼져 있을 때 하나의 트랜잭션에서 지연된 모든 로드 처리해야한다. 또한 보기 템플릿에서는 지연 로딩이 작동하지 않습니다.
따라서 트랜잭션이 끝나기 전에 지연 로딩을 강제로 호출해야 합니다.
명령과 쿼리의 분리
실제로 OSIV 꺼짐복잡성을 관리하는 좋은 방법이 있습니다. 명령과 쿼리를 분리하기 위한 것입니다.
일반적으로 비즈니스 로직은 특정 엔터티를 등록하거나 변경하는 것이므로 성능은 큰 문제가 아닙니다.
다만 복잡한 dynpro의 출력에 대해서는 dynpro에 따른 쿼리의 성능을 최적화하는 것이 중요하다. 그러나 복잡성으로 인해 핵심 비즈니스에 큰 영향을 미치지 않습니다. 따라서 대규모의 복잡한 응용 프로그램을 개발하는 경우 유지 관리 관점에서 둘 사이의 문제를 명확하게 분리하기로 결정하는 것이 합리적입니다.
간단히 설명하자면 다음과 같이 구분됩니다.
– OrderService: 핵심 비즈니스 로직 구현
– OrderQueryService: 화면 또는 API에 맞게 조정된 서비스(일반적으로 읽기 전용 트랜잭션)
트랜잭션은 일반적으로 서비스 수준에서 관리됩니다. 두 서비스 모두 트랜잭션을 유지하면서 지연 로드를 사용할 수 있습니다.
참조!
고객 서비스의 실시간 API는 OSIV를 비활성화하고 다음과 같이 많은 연결을 사용하지 않는 장소 B. 관리자는 OSIV를 활성화합니다.