skip to content

Step Processing & Item Flow

2 roadmaps34 questions

How a step actually moves data: the chunk loop, readers, processors and writers, listeners, and the transaction boundary. This is where most practical Spring Batch questions live.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

A cleanup Tasklet that returns CONTINUABLE to delete data in batches fails halfway. What determines whether the restarted job resumes correctly, and how do you design for it?

level: principalimportance: should knowfreq 20%

basics

~20 s

Because each CONTINUABLE pass commits its own transaction, completed batches stay deleted. On restart the whole step re-runs execute() from the start, so correctness depends on the work being idempotent or on progress saved in the ExecutionContext.

open as a page

How do you keep non-transactional side effects (emails, REST calls, external queues) from being duplicated or corrupted when a chunk transaction rolls back?

level: principalimportance: should knowfreq 33%

basics

~20 s

Rollback only undoes transactional resources, not emails or REST calls. Make those side effects idempotent, or defer them until after commit, or stage them in the same transactional store and process later. Never assume rollback un-does external effects.

open as a page

You need to read a large XML file with StaxEventItemReader inside a multi-threaded step, and guarantee correct restart. What issues arise and how do you address them?

level: principalimportance: nice to knowfreq 40%

basics

~20 s

StaxEventItemReader streams XML fragments via StAX and is stateful, so it is not thread-safe and its restart state can't be safely shared across threads. Either keep the step single-threaded, wrap it in SynchronizedItemStreamReader, or partition the input; be aware synchronizing serializes reads and can make saved state inconsistent.

open as a page

You must write each chunk to an external REST API that has no batch endpoint and is only at-least-once reliable. How do you design the ItemWriter for correctness under Spring Batch retries/restarts?

level: principalimportance: nice to knowfreq 22%

basics

~20 s

Implement a custom ItemWriter that loops the chunk calling the API, but make each call idempotent (send a client-generated idempotency key per item) so retries and restarts don't create duplicates. Track progress so restart resumes cleanly.

open as a page

showing 31–34 of 34