Spring Batch: Chunk-Oriented Processing End-to-End

Q: Spring Batch: Chunk-Oriented Processing End-to-End

Spring Batch **chunk-oriented processing** reads items one at a time (`ItemReader`), transforms them (`ItemProcessor`), then writes them in a **batch of N** (`ItemWriter`) inside a single transaction. The cycle is: read → process → accumulate until chunk-size → write + commit. If any step fails, the **whole chunk rolls back**; `skip` and `retry` policies let you tolerate bad records or transient failures without killing the job. Typical chunk sizes are 50-1000 for JDBC; tune based on row size and DB round-trip cost. Use **tasklets** for one-shot operations (file cleanup, stored-proc calls) where there's no natural stream of items.

Intermediate·2 min read·

SpringGoldman SachsJP MorganCitiCapital One

Fast recall

Quick revision

Core answer

Spring Batch chunk-oriented processing reads items one at a time (ItemReader), transforms them (ItemProcessor), then writes them in a batch of N (ItemWriter) inside a single transaction. The cycle is: read → process → accumulate until chunk-size → write + commit. If any step fails, the whole chunk rolls back; skip and retry policies let you tolerate bad records or transient failures without killing the job. Typical chunk sizes are 50-1000 for JDBC; tune based on row size and DB round-trip cost. Use tasklets for one-shot operations (file cleanup, stored-proc calls) where there's no natural stream of items.

Interview-ready guide

Interview answer

Spring Batch chunk-oriented processing reads items one at a time via ItemReader, transforms them with ItemProcessor, then writes them in a batch of N via ItemWriter inside a single transaction. If any step fails, the whole chunk rolls back; skip and retry policies let you tolerate bad records or transient failures without killing the job.

The chunk lifecycle:

Begin transaction
Read up to chunk_size items, processing each as it arrives
Pass the buffered list to ItemWriter.write(items) in one call
Commit transaction

Skip vs retry:

Skip — for bad records that should be logged and ignored
Retry — for transient failures like DB deadlocks or network blips
Both require .faultTolerant()

The single-item recovery cycle is the subtle part:

When a write fails, Spring Batch rolls back the chunk and re-reads each item individually
The good items are written one at a time; the bad item is skipped or fails the step
This is why processors must be idempotent — they may run twice for the same input

Tuning advice:

Chunk size 100-500 for JDBC; measure to find the sweet spot
JdbcBatchItemWriter usually matters more than chunk size for throughput
For JPA writers, set hibernate.jdbc.batch_size=50 and hibernate.order_inserts=true

Tasklet vs chunk:

Chunk for streaming work (process every row in X)
Tasklet for one-shot work (delete old files, call a stored procedure)

In an interview, I'd emphasize the single-item recovery mechanism and the idempotency requirement — those are what catch candidates.

03 · Deep dive