ItemReader, ItemProcessor, and ItemWriter: Chunk Processing in Spring Batch
Fast recall
Quick revision
Core answer
null to skip), and `ItemWriter` receives the entire chunk as a list to persist in one transaction. This separation makes each piece independently testable and swappable. The contract details — read() returns null at end-of-data, process() returns null to filter, write() receives Chunk (Spring Batch 5) so a single bulk INSERT replaces N round-trips — are what make chunk steps fast and restart-safe.Whether the candidate can wire a real-world data pipeline and understands the transaction boundary at the write phase
Returning null from `ItemProcessor` to skip an item is correct, but many candidates try to throw an exception instead, which triggers retry/skip logic unintentionally
Explain that `ItemReader.read()` returns null to signal end-of-data, and that `ItemWriter` receives a `Chunk<O>` (Spring Batch 5) rather than a plain List, plus the single-item retry behaviour on write failure
Interview-ready guide
Interview answer
The chunk-oriented step has three roles, each with a precise contract.
`ItemReader` — read one item at a time
- Spring Batch calls
read()repeatedly until it returnsnull nullis the normal end-of-data signal; throwing is for errors- Built-in readers:
FlatFileItemReader,JdbcCursorItemReader,JdbcPagingItemReader,JpaPagingItemReader,KafkaItemReader
`ItemProcessor` — transform or filter one item
- Receives one item; returns the transformed item or
nullto skip nullsilently removes the item from the chunk — never reaches the writer- Stateless by design; compose with
CompositeItemProcessor
`ItemWriter` — write the entire chunk
- Receives
Chunk(Spring Batch 5) — all processed items - Bulk INSERT/UPDATE in one DB call; never loop and write one at a time
- Built-in writers:
JdbcBatchItemWriter,JpaItemWriter,FlatFileItemWriter,KafkaItemWriter
Fault tolerance subtlety:
- Skip on write failure triggers a chunk rollback and single-item replay to isolate the bad row
- Every item in the failed chunk reprocesses — processors must be idempotent
- Non-transactional side effects (emails, API calls) are NOT rolled back; use a final tasklet or outbox pattern
Thread safety:
FlatFileItemReaderandJdbcCursorItemReadermaintain cursor state — wrap inSynchronizedItemStreamReaderfor multi-threaded steps- Paging readers are safer for concurrency since each page is independent
In an interview I'd emphasize the null-return semantics and the single-item retry behaviour — those are what catch candidates.
ItemReader, ItemProcessor, and ItemWriter: Chunk Processing in Spring Batch
Direct Answer
In chunk-oriented processing, ItemReader reads one item at a time until the chunk size is reached, ItemProcessor optionally transforms or filters each item (returning null to skip), and ItemWriter receives the entire chunk as a list to persist in one transaction. This separation makes each piece independently testable and swappable. The contract details — read() returns null at end-of-data, process() returns null to filter, write() receives Chunk<T> (Spring Batch 5) so a single bulk INSERT replaces N round-trips — are what make chunk steps fast and restart-safe.
Common Mistakes & Pitfalls
Returning null from ItemProcessor to skip an item is correct, but many candidates try to throw an exception instead, which triggers retry/skip logic unintentionally
Check your understanding
Answer these without looking back at the article.
- How would you chain multiple ItemProcessors together for different transformation stages?
- What is the difference between ItemWriter receiving a List versus a Chunk in Spring Batch 5?
- How does Spring Batch handle a scenario where ItemProcessor throws a runtime exception mid-chunk?
- Why must ItemProcessors be idempotent when fault tolerance is enabled?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.