writer retry 관련해서 궁금한 점이 있습니다.

죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.

4장. 작전3: FaultTolerant - 재시도로 구원하고, 스킵으로 처단하라 🏴‍☠️

작성

반말은 조금 부끄러워서.. 존댓말로 질문드리겠습니다.

ItemWriter에서 예외 발생 시 재시도 - 청크 단위로 재시도 관리

1. ItemWriter에서 예외 발생 시 ItemProcessor부터 처리가 재개된다.

2. ItemProcessor에서와 달리, ItemWriter에서의 재시도 횟수는 청크 단위로 관리된다.

요 부분에서 실제로 배치를 돌려보니 writer부터 재시작하는 것을 확인 가능했습니다.. 관련해서 원인을 분석해보니, 아래 결론에 도달했는데 맞을까요?

processorNonTransactional() 설정이 켜져있으면 Item 단위로 처리 결과를 캐시에 저장하기때문에 processor는 모두 완료 처리 -> writer부터 시작
processorNonTransactional() 설정이 꺼져있으면 청크 단위로 완료 처리하기때문에 processor부터 다시 시작

java spring spring-boot spring-batch backend

답변 2

KILL-9

지식공유자

#!/bin/bash
# KILL-9 Response System v1.0

echo ">> 반갑다 dj형. 좋은 질문이다."
echo ""
echo "[!] 결론부터: processorNonTransactional()과 재시도 컨텍스트 관리는 별개다."
echo ""
echo "=== 재시도 메커니즘 분석 ==="
echo ""
echo "▸ ItemProcessor 재시도: Item 단위 RetryContext"
echo "▸ ItemWriter 재시도: Chunk 단위 RetryContext"
echo "▸ 이건 processorNonTransactional() 설정과 무관하게 작동한다."
echo ""
echo "=== Writer 예외 발생 시 실제 동작 ==="
echo ""
echo "0) inputs Chunk(ItemReader가 생성)는 무조건 재사용된다."
echo "   → 상세 내용: 4장 작전4 참조"
echo ""
echo "1) inputs Chunk 내 아이템을 반복하며 ItemProcessor.process() 호출"
echo "   → outputs Chunk 생성 (ItemWriter에 전달될 청크)"
echo ""
echo "   1-1) processorNonTransactional() = true"
echo "        → ItemProcessor 재호출 X"
echo "        → 캐시된 데이터가 outputs Chunk에 담김"
echo ""
echo "   1-2) processorNonTransactional() = false (기본값)"
echo "        → ItemProcessor 재호출 O"
echo "        → process() 호출 결과가 outputs Chunk에 담김"
echo ""
echo "=== 결론 ==="
echo "네가 관찰한 'Writer부터 재시작'은 processorNonTransactional()=true 때문이다."
echo "캐시가 있으니 Processor를 건너뛴 것처럼 보이는 거지."
echo "재시도 컨텍스트 자체는 여전히 Item/Chunk 단위로 분리 관리된다."
echo ""
echo ">>> 4장 작전4에서 코드 레벨로 해부 예정"
echo ""
kill -9 $$

인프런 AI 인턴

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

박정선님께서 ItemWriter에서 예외 발생 시 재시도 작동 방식과 processorNonTransactional() 설정에 대해 질문 주셨네요. Spring Batch에서의 재시도 메커니즘은 데이터 일관성과 성능을 동시에 고려하여 설계되기 때문에 이 부분에 대해 잘 이해하고 계신 듯합니다.

ItemWriter 예외와 재시도 메커니즘

ItemReader와 ItemProcessor:
- 기본적으로 ItemReader와 ItemProcessor는 데이터 변환 과정을 거쳐 ItemWriter로 전달됩니다. 이때 데이터의 가공된 상태는 주로 메모리에 저장됩니다.
ItemWriter에서의 예외 핸들링:
- ItemWriter가 데이터를 쓰다가 예외가 발생하면, 해당 청크의 트랜잭션이 롤백됩니다. processorNonTransactional() 설정의 여부와 관계없이, ItemWriter는 데이터 저장의 마지막 단계이므로 해당 청크 안의 모든 데이터를 다시 기록하려 시도합니다. 다만, processorNonTransactional()이 켜져 있다면 ItemProcessor에 의해 변환된 상태가 유지된다는 장점이 있습니다.
processorNonTransactional()의 동작:
- processorNonTransactional()이 켜져 있는 경우: ItemProcessor의 결과를 캐시에 저장하므로 실패 시 ItemWriter만 다시 시도하게 됩니다. ItemProcessor의 결과는 이미 처리 완료된 것으로 간주되어, 다시 실행하지 않습니다.
- processorNonTransactional()이 꺼져 있는 경우: 트랜잭션 보장이 필요하다고 판단하면, 모든 청크의 과정(ItemReader, ItemProcessor, ItemWriter)이 완전히 롤백된 후, ItemProcessor부터 다시 실행됩니다.

결론

박정선님이 분석하신 대로, processorNonTransactional() 설정이 예외 처리 시 데이터 흐름에 많은 영향을 미치기 때문에 이를 통해 다르게 동작하게 됩니다. 설정에 따라, 예외 발생 시 ItemProcessor와 ItemWriter의 재시도 경계가 달라지게 됩니다.

유사한 내용에 대한 더 자세한 이해를 돕기 위해 관련 답변을 참고하실 수 있습니다: ItemWriter 재시도와 커밋 범위 이해하기

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변