3월 7일 JPA OSIV 와 성능최적화

Open Session In View = 하이버네이트

Open Entity Manager In View = JPA

관계형 OSIV라 한다

 

기본값 Spring , JPA , Open-in-view : true

이 기본값을 뿌리면서 애플리케이션 시작시점에 warm 로그를 남기는 이유가 있다.

기본적으로 JPA가 언제 DB커넥션을 가지고 오고 언제 DB커넥션을 반환하는지가 문제

 

영속성이 사용되려면 DB가 필수적으로 있어야한다.

DB트랜잭션이 시작할때 JPA가 DB커넥션을 가져온다.

DB에 커넥션을 돌려주는 시점은 차이가 있는데

open session in view가 켜져있으면 트랜잭션이 끝나도 반환을 하지 않는데

이유는 LAZY로딩이 일어날대 DB커넥션이 살아 있어야 하기 때문

 

Open Session in view 는 트랜잭션이 끝나도 영속성 컨텍스트를 끝까지 남겨둔다.

API의 경우 결과가 유저에게 반환될 때 까지남겨둔다.

 

화면의 경우에는 템플릿 렌더링 할때 까지 , 영속성과 DB커넥션을 끝까지 살려둔다.

요청이 끝날때 까지 살려두다가 렌더링이 끝나면 영속성과 DB커넥션이 종료된다.

 

이 open in view 가 true이기 때문에 지연로딩이 가능한것이다.

지연로딩은 영속성을 필수로 하고 영속성은 DB커넥션을 필수로 필요로한다.

 

치명적 다점이 존재하는데 너무 오래 DB커넥션을 살려두게 되면 커넥션 장애를 유발

 

장점은 엔티티를 적극활용이 가능하다는것.

 

Spring . jpa open in view : false  , OSIV 종료

OSIV를 끄게되면 트렌젝션이 유지되는 동안만 DB 커넥션과 영속성이 유지된다.

OSIV를 뜰때 장점은 DB 커넥션을 짧은 시간만 유지하는것

커넥션 리소스를 낭비하지 않는다.

 

치명적 단점 , 영속성 커넥션이 끝나기 떄문에 트랜잭션 이외에서 지연로딩이 되지 않는다.

그래서 트랜잭션 내에서 지연로딩을 완료시켜야 한다.

 

트랜잭션은 service , repository에서만 살아있기 때문에

이외에는 지연로딩을 하려고 하면 500에러가 발생한다

이를 트랜잭션 안에서 다 해결하거나 fetch join을 사용해야 한다

 

해결법

orderQuerySerivce를 만들면 된다. 쿼리 전용 service 

Container에서의 DTO로 데이터를 변환하는 로직을 serivce로 가져가는것

즉 트랜잭션이 끝나지 않는 범위 내에서 작업을 완료하는것이다.

 

성능 이슈는 주로 조회에서 발생한다.

 

*관심사를 나누어서 개발하는것을추천

orderService : 핵심 비즈니스 로직

orderQueryService : 화면에나 API에 맞춘 서비스 (주로 읽기전용 트랜잭션을 사용)

 

OSIV를 켜면 커넥션을 한계는 있지만 코드가 자유롭다.

OSIV를 끄면 커넥션에 성능을 최적화 해주지만 코드에 제약이 생긴다.