멀티스레드 환경에서의 트랜잭션 및 lock 관련 질문드립니다.

트랜잭션

스프링 배치에서 트랜잭션은 기본적으로 생성되는 TransactionManager 가 관리하게 되는데 배치를 실행하는 시점 즉 JobLauncher.run() 으로 Job 을 실행하고 JobRepository 가 트랜잭션을 얻어서 처리를 할 때 만약 이미 활성화 된 트랜잭션이 존재 할 경우 오류를 내 뱉고 있습니다. 가령 다음과 같은 상황입니다.

@Bean
public ApplicationRunner applicationRunner(){
    return new ApplicationRunner() {
        @Override
        @Transactional
        public void run(ApplicationArguments args) throws Exception {
            JobParameters jobParameters = new JobParametersBuilder().addDate("date", new Date()).toJobParameters();
            jobLauncher.run(job,jobParameters);
        }
    };
}

위에 보시면 JobLauncher.run() 이 실행되기 전 이미 @Transactional 이 선언되어 트랜잭션이 활성화 된 상태이기 때문에 오류가 발생합니다.

" Existing transaction detected in JobRepository. Please fix this and try again (e.g. remove @Transactional annotations from client)."

그렇기 때문에 스프링 배치에서 트랜잭션은 외부에서 이미 생성된 별도의 트랜잭션이 존재할 경우 이를 기본적으로 허용하지 않고 있습니다. 특별한 이유가 아니면 스프링 자체 트랜잭션과 스프링 배치의 트랜잭션을 별도로 운용할 필요는 없습니다. 다만 옵션 설정을 통해 이 부분도 해결은 가능합니다.

JobRepository 를 생성하는 초기화 과정에서 다음과 같이 커스텀하게 구현할 수 있습니다.

@Bean
protected JobRepository createJobRepository() throws Exception {
    JobRepositoryFactoryBean factory = new JobRepositoryFactoryBean();
    ----
    ----        
    factory.setValidateTransactionState(false);
    return factory.getObject();
}

위에서 factory.setValidateTransactionState(false); 하시면 이미 존재하는 외부의 트랜잭션 활성화 여부를 체크하지 않습니다. 그러면 오류가 발생하지는 않지만 그 외 이슈가 발생할 수 있으니 신중하게 접근해야 합니다. 기본은 true 입니다. 참고하시면 될 것 같습니다.

org.hibernate.LazyInitializationException 관련 문제는 Jpa 에서 세션이 종료된 상황에서 연관관계를 참조할 경우에 발생하는데 이 부분은 트랜잭션이 이미 종료된 상황이기 때문에 오히려 트랜잭션이 필요한 상황입니다. 이 경우도 여러가지 상황에서 발생할 수 있는 오류입니다. 어디에서 트랜잭션을 벗어나 있는지 체크해 보시기 바랍니다.

멀티스레드 환경의 chunk 배치

멀티 스레드에서 데이터를 읽어올 때 스프링 배치에서 제공하는 JpaPagingItemReader 는 동시성의 이슈가 발생하지 않도록 동기화 하고 있습니다. 그렇기 때문에 어떤 스레드에서 병목현상이 발생한다 할지라도 다른 스레드가 대기 상태에 있기 때문에 데이터를 중복적으로 읽어 올 수는 없습니다. 다만 지속적인 병목현상으로 인해 DB 커넥션이 끊어진다거나 메모리 누수 등의 문제로 어플리케이션이 멈추거나 종료가 될 수 있습니다.

이것을 해결하기 위해서는 스레드 5개가 각 아이템을 읽어올 때 스레드간 아이템이 겹쳐지지 않게 읽어오도록 구현하면 됩니다. 만약 A 스레드에서 병목 현상이 발생한다고 했을 때 B 스레드는 A 스레드의 아이템을 접근하지 않고 자신에게 할당한 아이템만 참조하도록 해야 합니다. 이 부분은 저의 강의에서 소개하고 있으니 참고해 주시기 바랍니다.

synchronizeditemstreamreader를 사용하는 경우 lock

보통은 DB Connection 은 pool 로 관리하기 때문에 스레드 갯수보다 커넥션 수가 많아야 된다는 기준은 없습니다. 스레드가 배치를 처리하는 시간보다 요청하는 스레드가 많을 경우 스레드가 대기를 타거나 DB 커넥션이 부족해서 위와 같이 오류를 발생할 수는 있습니다. 넓게 본다면 이부분은 스프링 배치의 문제라기 보다는 스레드와 DB 커넥션 풀 간의 운용에 관한 문제라 할 수 있습니다. 다만 스프링 배치에서 Synchronizeditemstreamreader 가 기능을 수행하기 위한 조건적인 측면에서 DB 커넥션 개수 기준을 특별하게 정했을 수도 있습니다. 저도 이 부분은 정확하게 테스트 해보지는 않았는데 한번 보도록 하겠습니다.