open-in-view

서론

프로젝트를 실행하는 과정에서 다음과 같은 WARN 메시지가 출력됐다. open-in-view가 활성화되어 있는데 이러면 뷰 렌더링 중에 데이터베이스 쿼리가 수행될 수 있다. 이를 비활성화할려면 설정해라 로 해석할 수 있다. 처음 이 메시지를 봤을 때, 뷰 렌더링 중에 쿼리가 발생할 수 있는 것이 왜 WARN 메시지인지 잘 몰랐다. 어떤 위험성이 있는지 알아봤다.

본론

정의

open-in-view를 통해 영속성 컨텍스트가 데이터베이스의 커넥션을 언제 돌려주는지 설정할 수 있다고 한다.

spring:
  jpa:
    open-in-view: /* true or false */

• true : 서버가 클라이언트에게 응답 메시지를 보낸 이후에 커넥션을 반납 (응답을 한 후)
• false : 데이터베이스 커넥션의 사용이 끝나면 바로 반납 (트랜잭션이 끝난 후)
• 커넥션을 반납한다 = 영속성 컨텍스트가 닫힌다로 보면 이해하기 편할 것 같다.

true일 때 왜 문제가 될까 ?

애플리케이션이 시작될 때, 데이터베이션의 커넥션을 미리 획득하여 커넥션풀에 저장을 한다. 이를 통해 요청때마다 데이터베이스의 커넥션을 획득하는 비용을 줄일 수 있다. 커넥션풀에 저장되는 커넥션의 기본 개수는 주로 10개라고하며, 설정을 통해 변경할 수 있다.

커넥션풀에 저장된 커넥션 10개가 클라이언트의 호출을 통해 반환됐다고 가정을 한다. 이중 커넥션의 사용이 끝나 더 이상 사용하지 않는 커넥션이 존재할 것이다.

이를 반납하지 않고 그대로 가지고 있다면, 이후에 들어오는 요청은 대기 상태에 있거나 커넥션을 획득하기 위해 TCP 3handshake를 진행할 것이다. 이렇게 되면 클라이언트의 대기 시간이 증가하고, 커넥션을 획득하기 위한 비용이 발생한다.

그럼 false로 설정해야 할까 ?

여기서도 문제가 발생한다. true로 설정을 해서 커넥션 풀을 반납을 하고, A라는 데이터를 가져왔다고 가정을 한다. A는 B와 연관관계를 가지고 있고 지연 로딩 기능을 사용한다.

A를 가져오고 commit이 되면, 트랜잭션은 닫히고 커넥션 풀도 반납이 된다. 이 상태에서 B를 조회하게 되면 조회가 되지 않고 에러가 발생된다. 왜냐하면, 지연 로딩은 조회 당시에는 프록시 객체를 집어 넣고 필요한 순간에 객체를 조회하는데 커넥션 풀이 반납 된 시점에서 프록시 객체가 어떤 객체의 프록시 객체인지 알 수 없기 때문이다.

더 자세히 설명하면, A를 가져오게 되면 영속성 컨텍스트에서 이를 관리한다. 트랜잭션이 끝나버려서 영속성 컨텍스트가 닫히게 되면 A는 준영속 상태로 변하게 된다. 여기서 A와 연관 관계가 있는 B의 프록시 객체를 통해 B를 조회할려고 하면 조회가 안된다. 왜냐하면, 엔티티가 영속 상태여야 조회가 가능하며 영속성 컨텍스트가 닫힌 시점에서 준영속 상태를 영속 상태로 바꿀 수 없기 때문이다.

이를 해결하기 위해서는 최초에 열린 트랜잭션에서 연관 관계가 있는 데이터를 모두 조회해야 한다.

그럼 true와 false 둘 중 어떤걸로 설정을 해야 할까 ?

정답은 없는 것 같다. 구현하는 애플리케이션에 따라 설정이 달라진다고 생각을 했다. true로 설정하면 커넥션풀의 기본 크기를 크게 잡고, false로 설정하면 트랜잭션 내에서 모두 처리가 되거나 지연 로딩을 사용한 데이터를 모두 로드하는 로직을 구성하면 된다.

프로젝트 적용

유저가 생성이 되면 응답으로 유저의 역할이 기본값으로 나와야하는데, null 값으로 나와서 해결책을 찾던 중 머리 한 구석에 있던 open-in-view 설정이 생각이 났다. 영속성 컨텍스트가 유지되는 동안 영속된 유저 엔티티에는 역할이 null 값이였다. open-in-view를 false로 설정하고, 다음과 같이 코드를 작성하면 유저의 역할이 정상적으로 출력이 된다.

@PostMapping("/user")
public ResponseEntity < ResponseUser > createUser(
    @Valid @RequestBody RequestCreateUser requestCreateUser
) {
    userService.createUser(requestCreateUser);
    ResponseUser user = userService.findUserByUsername(requestCreateUser.username());
    return ResponseEntity.ok(user);
}

영속성 컨텍스트가 유지되는 동안에 유저를 검색하면 영속성 컨텍스트에서 조회를 한다. 이때는 순수 입력된 값으로 구성된 유저의 엔티티가 영속성 컨텍스트에 존재한다.

생성이 끝나고 영속성 컨텍스트를 닫고, 다시 검색을 하게 되면 새로 열린 영속성 컨텍스트에는 유저 엔티티가 없기 때문에 데이터베이스에서 조회해서 가져온다. 그럼 기본값이 모두 들어간 유저 엔티티를 가져올 수 있다.

마무리

이 내용은 사실 JDBC 학습 때 애플리케이션 시작 과정에서 에러 메시지가 나오길레 궁금해서 한 번 찾아봤던 내용이다. 그 때는 이런 내용이구나 하고 인지하고 넘어갔는데, 프로젝트 구현 과정에서 필요하다고 생각되서 정리했다. 무심코 지나간 내용이 해결책이 됨을 알게 됐고, 사소한 것 하나하나라도 알아둘 필요가 있음을 알게 됐다.

이후 프로젝트 진행 과정에서 지연 로딩을 사용하는 객체들이 존재함을 알게 됐고 또 다시 삽질을 해야한다는 현실을 마주했다. 허허허허

참고 문헌

Spring Boot의 open-in-view, 그 위험성에 대하여. spring.jpa.open-in-view 란? OSIV(Open Session in view)이란? 장단점, 써야할지 말아야할지