청크 단위의 트랜잭션 롤백에 대한 질문

작성한 질문수 14

1

$ cat answer.txt

좋은 질문이다

> "ItemReader, ItemProcessor에서 Exception 나도 DB 롤백할 게 없으니 실질적으론 ItemWriter에서만 롤백되는 거 아닌가?"

괴상한 커스텀 구현이 아니고서야 일반적으로 너의 말이 옳다
ItemReader는 읽기만, ItemProcessor는 변환만 하니까
실제 롤백 대상은 ItemWriter의 쓰기 작업이 맞다

$ but wait...

그렇다고 ItemReader/ItemProcessor가 트랜잭션 안에 묶인 게(청크 단위로 트랜잭션 경계가 정해진다는게) 
무의미한 건 아니다

# Case 1: 데이터 일관성 보호
ItemReader가 DB에서 데이터를 읽는다고 치자
이 읽기 작업은 트랜잭션 격리수준의 보호를 받는다
(REPEATABLE_READ라면 스냅샷 격리)  

외부의 변화로부터 독립된 읽기가 가능하다는 뜻이지
- 청크 처리 중간에 다른 트랜잭션이 데이터 변경해도
- 현재 청크는 시작 시점의 일관된 데이터로 작업한다

// 커서 기반 ItemReader를 사용하느냐 Paging 기반 ItemRreader를 사용할 때 페이지 사이즈의 크기가 어떤지 등의 복잡성을 일으키는 내용은 무시하자


# Case 2: ItemProcessor의 추가 조회
ItemProcessor 안에서 추가 DB 조회하는 경우:
User user = userRepository.findById(item.getUserId());

이 조회도 동일한 트랜잭션/격리수준의 보호를 받는다
ItemReader가 읽은 시점과 일관된 데이터를 보장받는 거지

$ summary
- 롤백 대상은 주로 ItemWriter 맞다
- 하지만 ItemReader + ItemProcessor가 같은 트랜잭션 = 일관된 데이터 읽기/가공 보장

chmod +x consistent_data.sh

참고 1): ItemReader가 커서 방식이냐 페이징이냐(또 여기선 페이지 크기가 어떻냐 청크 사이즈는 어떻냐 등), 격리 수준은 어떻냐 등에 따라 이야기가 복잡해질 수 있는데 이런 내용은 이해에 복잡도만 올리니 무시하자

- KILL-9

0

안녕하세요, 인프런 AI 인턴입니다.

tjrwn0716님께서 청크 단위 트랜잭션 롤백에 대해 질문을 주셨네요. Spring Batch에서 트랜잭션 처리는 청크 단위로 이루어지며, 이는 데이터 처리의 안정성을 유지하기 위한 중요한 기능입니다.

청크 단위 트랜잭션의 롤백

1. 청크 트랜잭션의 범위

   • 청크 단위 트랜잭션은 ItemReader, ItemProcessor, 및 ItemWriter가 모두 포함됩니다. 따라서, 읽기, 처리, 쓰기 각각의 단계에서 예외가 발생하면 전체 청크가 롤백됩니다.
     

2. 롤백의 실제 수행

   • ItemReader나 ItemProcessor에서 발생한 예외 또한 트랜잭션 롤백을 유발합니다. 예외가 발생하면 현재 처리 중이던 청크 전체가 롤백되며, 이는 항상 ItemWriter 이후에만 롤백되는 것이 아니기 때문에 tjrwn0716님께서는 read나 process 중에도 롤백이 발생할 수 있음을 염두에 두셔야 합니다.
     

3. 트랜잭션 롤백 예시

   • 가령 read() 메서드가 현재 청크 사이즈의 중간에서 실패하면, 해당 청크의 부분적인 작업들은 모두 롤백됩니다.
     
   • process() 메서드에서도 오류가 발생하면 마찬가지로 트랜잭션이 롤백됩니다. 이러한 동작은 데이터의 일관성을 유지하는데 중요한 역할을 합니다.
     

관련된 내용을 더 깊이 이해하시려면, Spring Batch의 공식 문서 및 아래의 유사한 질문을 참고하시길 권장드립니다:
- 청크 단위 트랜잭션과 롤백의 이해

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.

현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.