트랜잭션 범위 질문

네

이부분은 스프링 배치의 트랜잭션 흐름을 조금 상세하게 알아야 하는데요..

기본적으로 스프링 배치에서는 read, process, write 의 프로세스를 하나의 트랜잭션으로 감싸고 있습니다.

이 트랜잭션은 Tasklet 안에서 시작하고 종료하게 됩니다.

여기서 만약 Tasklet 에 @Transactional 을 선언했다면 스프링 배치의 기본 트랜잭션 외부에 별도의 트랜잭션이 위치하게 됩니다.

스프링 배치에서 생성한 트랜잭션은 트랜잭션을 시작하고 종료할 때까지 어플리케이션 단에서 하나의 Lock 으로 동기화 하고 있습니다. 즉 트랜잭션 시작시 Lock 을 획득하고 트랜잭션 종료시 Lock 을 해제하는 식으로 되어 있습니다. 그리고 이 조건은 트랜잭션이 커밋하는 시점과 맞물려 있습니다.

스프링에서 트랜잭션의 전파는 기본적으로 이전의 트랜잭션을 계속 물려 받도록 되어 있습니다.
즉 Tasklet 에서 선언한 @Transactional 트랜잭션을 스프링 배치의 기본 트랜잭션이 물려 받아 실행이 되는데 문제는 스프링 배치의 기본 트랜잭션이 Lock 을 획득하고 해제하는 시점이 @Transactional 을 통한 외부의 트랜잭션이 시작하고 해제하는 시점과 틀려서 일종의 데드락이 발생한다는 점입니다.

즉 @Transactional 의 트랜잭션이 시작할 때 Lock 을 획득하고 Tasklet 이 실행되다가 스프링 배치의 기본 트랜잭션이 동일하게 Lock 을 획득할려고 하는데 @Transactional 에서 획득한 Lock 이 아직 커밋 시점이 오지 않아서 해제가 되지 않게 되고 그래서 스프링 배치의 기본 트랜잭션도 Lock 획득하기 위해 계속 대기해야 하는 상황이 발생하게 됩니다.

이런 상황을 해결하기 위해서는 스프링 배치에서 이전의 @Transactional 트랜잭션을 물려 받는 것이 아니라 새롭게 트랜잭션을 생성하는 전파 방식을 선언한면 됩니다.

예를 들어 PROPAGATION_REQUIRES_NEW 전파 방식을 별도로 새롭게 정의하면 됩니다.

하지만 이 역시도 이전의 트랜잭션과 독립적으로 움직이기 때문에 데이터 일관성이 깨지는 문제가 발생할 수 있습니다.

그래서 스프링 배치에서는 @Transactional 와 같은 외부 트랜잭션을 선언하는 것을 원칙적으로 금지하고 있다고 보시면 됩니다.