Spring에서 트랜잭션을 통한 비동기 실행 처리: 일반적인 함정 및 해결 방법

최신 Spring 애플리케이션에서는 비동기 실행과 트랜잭션 동작을 결합하는 것이 일반적입니다. 그러나 @Async 및 @Transactional(propagation = Propagation.REQUIRES_NEW)을 사용하여 메서드에 주석을 추가하면 Spring이 비동기 작업과 트랜잭션을 관리하기 때문에 예기치 않은 동작이 발생할 수 있습니다.

이 기사에서는 문제를 자세히 살펴보고 비동기 실행과 트랜잭션 관리를 모두 올바르게 처리하는 솔루션을 보여 드리겠습니다.

문제: @Async 및 @Transactional(propagation = Propagation.REQUIRES_NEW)

다음 코드 조각을 고려하세요.

@Async
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveSomething() {
    // save-point one
    // save-point two
}

얼핏 보면 모든 것이 예상대로 작동하는 것처럼 보일 수 있습니다. 그러나 이 구성에는 의도하지 않은 동작을 초래할 수 있는 몇 가지 주요 문제가 있습니다.

뒤에서 무슨 일이 일어나는가?

• @Async 주석:

@Async 주석은 Spring에게 별도의 스레드에서 메서드를 비동기적으로 실행하도록 지시합니다. 이는 메소드가 호출된 원래 스레드에서 실행되지 않고 스레드 풀의 다른 스레드로 오프로드됨을 의미합니다.
Spring은 비동기 메소드를 관리하기 위해 프록시를 사용합니다. @Async로 주석이 달린 메서드를 호출하면 Spring은 다른 스레드에서 메서드를 실행하는 내부 실행자에게 실행을 위임합니다.

• @Transactional(propagation = Propagation.REQUIRES_NEW) 주석:

@Transactional(propagation = Propagation.REQUIRES_NEW) 주석은 기존 트랜잭션에 관계없이 해당 메소드에 대해 새 트랜잭션이 시작되도록 보장합니다. 호출 스레드의 모든 활성 트랜잭션을 일시 중지하고 해당 메서드에 대한 새 트랜잭션을 시작합니다.

Spring의 트랜잭션 관리는 일반적으로 스레드에 바인딩되어 있습니다. 즉, 트랜잭션 컨텍스트가 현재 스레드에 연결되어 있다는 의미입니다.

갈등

@Async가 다른 스레드에서 메서드를 실행하고 Spring의 트랜잭션 관리가 트랜잭션을 바인딩하기 위해 스레드에 의존하기 때문에 문제가 발생합니다. 메서드가 비동기적으로 실행되면 호출 스레드의 트랜잭션 컨텍스트가 새 스레드로 전파되지 않아 다음과 같은 문제가 발생합니다.

• @Transactional 주석은 비동기 스레드에서 새 트랜잭션을 생성하지 않으며 모든 트랜잭션 동작(예: 롤백, 커밋 등)이 올바르게 처리되지 않습니다.
• REQUIRES_NEW 전파 설정은 비동기 메서드가 원래 트랜잭션 컨텍스트 외부에서 실행되기 때문에 적용되지 않습니다.

해결책: 비동기 실행과 트랜잭션 분리

이 문제를 해결하려면 별도의 서비스 메서드에서 트랜잭션을 처리하여 트랜잭션 논리에서 비동기 실행을 분리할 수 있습니다. 방법은 다음과 같습니다.

• 1단계: 트랜잭션 논리를 위한 새로운 동기 서비스 생성
  트랜잭션 논리를 처리하는 새 서비스를 만듭니다. 이 메소드는 트랜잭션 관리가 예상대로 작동하는지 확인하기 위해 동기적으로(@Async 없이) 실행됩니다.

• 2단계: 비동기식으로 동기 메서드 호출
  그런 다음 @Async를 사용하여 동기 트랜잭션 메서드를 비동기적으로 호출할 수 있습니다. 이렇게 하면 트랜잭션 논리가 메인 스레드에서 올바르게 처리되고 비동기 동작이 계속 유지됩니다.

리팩토링된 코드는 다음과 같습니다.

@Async
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveSomething() {
    // save-point one
    // save-point two
}

어떻게 작동하나요?

리팩터링된 솔루션에서는 saveSomethingAsync() 메서드에 @Async 주석을 추가하여 비동기 실행을 수행합니다. 이는 saveSomethingAsync()가 호출되면 Spring의 비동기 작업 실행기가 관리하는 별도의 스레드에서 실행된다는 의미입니다. 이를 다른 스레드에서 실행하면 saveSomethingAsync()가 완료될 때까지 기다리지 않고 기본 스레드가 계속 실행될 수 있습니다. 이 접근 방식은 장기 실행 작업의 부담을 덜어주고, 응답성을 향상시키거나, 독립적인 작업을 동시에 처리하려는 시나리오에 유용합니다.

트랜잭션 동작의 경우 TransactionalService의 saveSomething() 메서드에 @Transactional(propagation = Propagation.REQUIRES_NEW) 주석이 추가됩니다. 이렇게 하면 saveSomething()을 호출할 때마다 호출 메서드의 기존 트랜잭션과 관계없이 새 트랜잭션이 생성됩니다. REQUIRES_NEW 전파는 새로운 트랜잭션을 시작하고 기존 트랜잭션을 일시 중지하여 saveSomething()이 격리된 트랜잭션 컨텍스트에서 작동할 수 있도록 합니다. 즉, 원래 호출 메서드에 트랜잭션이 있더라도 saveSomething()은 별도의 자체 트랜잭션 내에서 작동하여 이 작업에 대해서만 제어된 커밋 및 롤백이 가능합니다.

트랜잭션 논리에서 비동기 실행을 분리함으로써 트랜잭션 관리가 예상대로 작동하도록 보장합니다. 이 설정에서 트랜잭션 컨텍스트는 saveSomething() 메서드 내에서 올바르게 처리되는 반면 saveSomethingAsync() 메서드는 별도의 스레드에서 계속 실행됩니다. 이러한 우려의 분리를 통해 비동기식 처리와 안정적인 트랜잭션 관리의 이점을 모두 얻을 수 있으므로 동시에 처리하는 경우에도 독립적이고 안전한 데이터 작업이 가능합니다.

이 접근 방식을 언제 사용해야 합니까?

• 트랜잭션 격리가 중요한 경우: 특정 작업이 별도의 트랜잭션(예: REQUIRES_NEW)에서 수행되도록 해야 하는 경우 이 접근 방식이 효과적입니다.

• 비동기 작업: 비동기식으로 실행해야 하지만 자체 트랜잭션 경계가 필요한 장기 실행 독립 작업이 있는 경우.

대안: 완전한 분리를 위해 메시지 대기열 사용

고급 분리가 필요하거나 재시도, 오류 처리, 장기 실행 프로세스를 처리하려는 경우 작업을 Kafka 또는 RabbitMQ와 같은 메시지 대기열로 오프로드하는 것을 고려해 보세요. 메시지 대기열을 사용하면 각 작업이 자체 컨텍스트에서 실행되고 트랜잭션이 독립적으로 관리될 수 있습니다.

위 내용은 Spring에서 트랜잭션을 통한 비동기 실행 처리: 일반적인 함정 및 해결 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!