외부 API 호출을 트랜잭션에서 분리하기 위해 FACADE 계층을 사용한다면, OSIV 활성화 여부를 고려하자!

문제 상황: 서로 다른 트랜잭션에서 엔티티 변경 시 변경감지가 작동하는가?

외부 API 호출을 트랜잭션에서 분리하기 위해 FACADE 패턴을 도입했습니다.
3개의 서비스를 리팩토링하며, 트랜잭션 범위 밖에서 외부 API를 호출하도록 설계하였고, 코드 구조는 다음과 같았습니다.

// 트랜잭션에서 외부 API 호출을 분리하고자 만든 Facade 객체
public class Facade {

    private final Service1 service1;
    private final Service2 service2;

    public ... createSomething(...) {
        // 1번 서비스 트랜잭션 시작
        EntityA entityA = service1.doSomething(...);

        // 외부 API 호출 (트랜잭션 외부)
        externalApi.call();

        // 1번 서비스의 반환값을 2번 서비스의 파라미터로 전달
        service2.processSomething(entityA);
    }
}

여기서 문제는 1번 서비스의 반환값인 entityA를 2번 서비스에서 변경할 때, 변경감지(dirty checking)가 적용되는지 여부였습니다. 즉, 서로 다른 서비스의 트랜잭션에서 영속성 컨텍스트의 변경감지를 활용할 수 있는가에 대한 확인이었습니다.

 

해결 과정: 영속성 컨텍스트와 트랜잭션의 관계 이해

이를 확인하기 위해서는 영속성 컨텍스트와 스프링의 트랜잭션이 어떤 상호작용을 하는지 알아야 합니다.

 

일반적으로 JPA의 영속성 컨텍스트는 트랜잭션마다 새로 생성됩니다.

예를 들어, A서비스에서 트랜잭션을 시작하고, B서비스의 트랜잭션이 있는 메서드를 호출할 때 트랜잭션 전파 옵션이 REQUIRES_NEW로 설정되어 있다고 가정을 한다면,

1. A서비스의 트랜잭션이 시작되며 A만의 영속성 컨텍스트가 생성됩니다.
2. B서비스 호출 시, 전파 옵션이 REQUIRES_NEW이므로 B에서 새로운 트랜잭션이 시작되며 B만의 영속성 컨텍스트가 생성됩니다.
3. B서비스는 A서비스와 전혀 다른 트랜잭션 및 영속성 컨텍스트를 사용하게 됩니다.

* 출처: 영속성 컨텍스트와 트랜잭션 propagation

 

따라서 FACADE 계층의 코드에서 1번 서비스의 트랜잭션이 커밋되고, 2번 서비스의 트랜잭션을 시작하게 되며 이는 서로 다른 트랜잭션입니다. 즉, 영속성 컨텍스트를 공유하지 않게 될 것이라고 예상할 수 있습니다.

 

하지만, 간과한 점: OSIV 설정 여부

하지만, 간과한 것이 있으니 OSIV 설정 여부입니다.

OSIV 란 영속성 컨텍스트 범위 내에서도 지연 로딩을 하기 위한 목적으로 영속성 컨텍스트의 생명 범위를 트랜잭션 범위 밖에서도 유지시켜서 엔티티를 준영속 상태가 아닌 영속상태로 유지하게 하는 것입니다.

 

스프링 부트에서 JPA를 사용할 경우, 기본적으로 OSIV가 활성화되어 있으며 서버를 실행할 때, WARN 로그를 통해 활성화 여부를 알 수 있습니다.

WARN JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning

 

즉, OSIV 활성화에 의해 영속성 컨텍스트의 생존 범위는 아래 사진처럼 HTTP 요청이 들어오고 나갈때 까지 생존 범위가 늘어나게 됩니다.

김영한님의 자바 ORM 표준 JPA 프로그래밍 책에 따르면 영속성 컨텍스트의 생존 범위는 다음과 같습니다.

1. 클라이언트의 요청이 들어오면 서블릿 필터나, 스프링 인터셉터에서 영속성 컨텍스트를 생성한다. 단 트랜잭션은 시작하지 않는다
   • 트랜잭션이 시작하지 않기 때문에 DB커넥션은 아직 획득하지 않습니다. DB커넥션과 같은 리소스는 트랜잭션 동기화 매니저(TransactionSynchronizationManager) 가 얻습니다.
2. 서비스 계층에서 @Transactional로 트랜잭션을 시작할 때 1번에서 미리 생성해둔 영속성 컨텍스트를 찾아와서 트랜잭션을 시작한다.
3. 서비스 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시한다. 이때 트랜잭션은 끝내지만 영속성 컨텍스트는 종료하지 않는다.
4. 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지한다.
5. 서블릿 필터나, 스프링 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료한다. 이때 플러시를 호출하지 않고 바로종료한다.

그래서, spring.jpa.open-in-view: false 설정을 통해 OSIV 기능을 끄지 않았다면 OSIV 활성화에 의해 1번 서비스와 2번 서비스는 같은 영속성 컨텍스트를 공유하게 되며 1번 서비스의 반환값인 엔티티 A는 2번 서비스에서 변경감지를 사용할 수 있을 것입니다.

 

OSIV 단점 : DB 커넥션 미 반납

그러나, 이는 여기서 옳지 못한 선택입니다.

OSIV 활성화로 인해 영속성 컨텍스트 범위가 늘어났다는 것은 트랜잭션을 시작하며 얻은 DB 커넥션을 HTTP 요청이 끝날때까지 반납하지 않게 됩니다.

 

즉, [1번 서비스 트랜잭션 시작]과 [2번 서비스 트랜잭션 시작] 사이에 있는 외부 API 호출할 때도 DB 커넥션을 유지하게 됩니다.

이는 외부 API 호출을 트랜잭션에서 분리하기 위해 FACADE 패턴을 도입해서 외부 API 호출하는 동안은 DB커넥션을 반납하고 트랜잭션을 짧게 유지하기 위한 목적이었지만, 정작 OSIV 활성화로 인해 외부 API 호출동안 DB커넥션이 반환되지 않는 꼴이 됩니다.

 

결론: OSIV 비활성화 및 코드 수정

이 문제를 해결하고자 yml 파일에 spring.jpa.open-in-view: false 설정을 주어 OSIV 설정을 끄도록 하겠습니다.

원래 궁금했던 '반환값 A가 서로 다른 서비스의 트랜잭션에서 변경감지를 사용할 수 있는가?' 에 대한 답은

• OSIV가 활성화된 경우: 1번 서비스(트랜잭션)와 2번 서비스(트랜잭션)에서 엔티티를 공유해서 변경감지를 사용할 수 있음.
  • 변경감지를 사용하려면 두 서비스에 트랜잭션이 꼭 있어야만 합니다. 트랜잭션이 있어야 영속성 컨텍스트의 내용을 DB로 flush 하기 때문
• OSIV가 비활성화된 경우: 서로 다른 트랜잭션에서 영속성 컨텍스트를 공유하지 않으므로 변경감지를 사용할 수 없음

하지만, 외부 API 호출을 트랜잭션에서 분리하기 위해 FACADE 패턴을 도입했다면, OSIV 의 활성화 여부를 고려해서 DB커넥션이 반납이 올바르게 되는지 비즈니스 로직을 검토할 필요가 있겠습니다. 저 또한, OSIV 활성화 여부를 끄고, 변경감지를 이용하지 않는 방식으로 코드를 수정하게 되었습니다.

 

마치며

사실 이 과정에서 다룬 OSIV 설정과 영속성 컨텍스트의 생명 주기는, 이전에 JPA 강의를 들으며 이미 학습했던 내용이었습니다. 하지만, 강의를 들을 당시에는 단순히 눈으로 보고 머리로 이해한 것에 그쳤고, 시간이 지나니 그 내용이 정확히 기억나지 않았습니다. 이번 프로젝트를 통해 스스로 고민하고 해결하는 과정에서 지식을 체화할 수 있었습니다.

물론, OSIV 를 고려해야 한다는 점은 강의를 미리 듣지 않았다면 더 늦게 깨달았을지도 모릅니다. 하지만 이번 경험을 통해 스스로 생각하고 지식을 활용할 때, 가장 의미 있는 학습을 할 수 있음을 다시 한번 느끼며 마무리 하겠습니다.  

 

 

참고

- '자바 ORM 표준 JPA 프로그래밍' 책

- F lab: 스프링 부트에서의 OSIV(Open Session In View) 패턴 이해와 적용