OSIV 파헤치기 - sse 구현 중 HikariPool-1 - Connection is not available 에러

sse를 사용한 실시간 알림 서비스 구현 후 서버가 잘 돌아가다 몇 번 요청 시도 끝에 뻗는 에러가 발생했다. 결론부터 말하면 DB와의 커넥션이 끊어지지않아 생긴 에러였다. 

 

이 에러를 해결 하면서JPA의 OSIV에 대해 다시금 공부할 수 있었다.

 

 

OSIV (open session in view)

 

OSIV의 동작 원리는 아래와 같다

• 클라이언트의 요청이 들어오면 서블릿 필터나, 스프링 인터셉터에서 영속성 컨텍스트를 생성한다. 단 이 시점에서 트랜잭션은 시작하지 않는다. 
• 서비스 계층에서 @Transeactional로 트랜잭션을 시작할 때 1번에서 미리 생성해둔 영속성 컨텍스트를 찾아와서 트랜잭션을 시작한다. 
• 서비스 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시한다. 이 시점에 트랜잭션은 끝내지만 영속성 컨텍스트는 종료되지 않는다. 
• 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지한다. 
• 서블릿 필터나, 스프링 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료한다.

 

사진에서 볼 수 있드시 서비스 계층에서 트랜잭션이 끝나면 컨트롤러와 뷰에는 트랜잭션이 유지되지 않는 상태이다. 엔티티를 변경하지 않고 단순히 조회만 가능하다.

이때 만약 프록시를 뷰 렌더링하는 과정에 초기화(Lazy loading)가 일어나게 되어도 조회 기능이므로 트랜잭션이 없이 읽기가 가능하다.

하지만 트랜잭션이 끝난 시점이기 때문에 수정은 불가능하다. 

 

 

OSIV 전략은 트랜잭션 시작처럼 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때 까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지한다.

그래서 View Template이나 API 컨트롤러에서 지연 로딩이 가능하다. 지연 로딩은 영속성 컨텍스트가 살아있어야 가능하고, 영속성 컨텍스트는 기본적으로 데이터베이스 커넥션을 유지한다. 이것 자체가 큰 장점이다.

 

하지만 이 전략은 너무 오랜시간동안 데이터베이스 커넥션 리소스를 사용하기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있다. 이것은 결국 장애로 이어진다.

 

 

OSIV와 SSE

OSIV와 SSE를 함께 사용할 땐 주의해야 할 점이 있다. SSE의 통신 개념은 이전 글에서 다룬 적이 가볍게 넘어가겠다. SSE는 서버에서 클라이언트와의 커넥션을 끊지않고 물고 있다가 event 발생 시 클라이언트로 데이터를 주는 개념이다.  내 코드에서 문제점은 알림을 보내는 서비스 클래스에 트랜잭션을 붙여놨던 것이었다. 

 

 

클래스 생성하며 아무 생각없이 붙였던 트랜잭션이 에러의 원인이라곤 생각하지 못 했다. 지금 생각하면 당연한건데 그땐 전혀 생각하지 못했다 ㅠㅠ..

헤더에 subscribe 로직을 넣어두고 페이지 이동할 때마다 subscribe 요청을 보냈는데 @Transaction이 걸려있어 DB와의 커넥션을 끊지 못 했던 것 같다.

 

다른 분들은 보통 sse를 구현할 땐 OSIV를 끄고 한다고 한다. 일반적으론 HTTP 호출이 끝나고 DB 커넥션도 종료되나, SSE 사용시에는 객체가 만료되기 전까지 계속해서 DB 커넥션이 열려 고갈되기 때문이다.

 

 

 

추가로 OSIV를 끄면 모든 지연로딩을 트랜잭션 안에서 처리해야 한다. 하지만 내가 짠 코드는 전부 트랜잭션 안에서 지연로딩을 수행했기 때문에 쉽게 끌 수 있었다.