Spring Batch

ExecutionContext is a persisted key/value map Spring Batch attaches to a running job or step. It stores state — like how many items were read — so if the job stops and restarts, it can pick up where it left off.

A JobInstance is a logical run of a job (job name + its identifying parameters). A JobExecution is a single attempt to run that instance. One JobInstance can have several JobExecutions if earlier attempts failed and were restarted.

A Job is an entire batch process. A Step is one independent phase of it. A Job contains an ordered list of Steps and runs them in sequence; each Step does a unit of work.

BatchStatus is an enum (COMPLETED, FAILED, STARTED, STOPPED...) describing a job's or step's lifecycle state. ExitStatus is a string-code object (exitCode plus description) used mainly to decide flow between steps. Both live on every JobExecution and StepExecution.

A StepExecution represents one attempt to run a Step. It records runtime metrics: readCount, writeCount, filterCount, commitCount, rollbackCount, and skipCount, plus status, timestamps, and its own ExecutionContext.

A Spring Batch step reads items one by one, optionally processes each, and writes them in batches. The commit-interval (the chunk size) is how many items are grouped and written together in one transaction before committing.

The reader reads one raw line, then hands it to a LineMapper. The LineMapper uses a LineTokenizer to split the line into fields (a FieldSet), and a FieldSetMapper to turn those fields into a domain object.

ItemProcessor is the middle stage of a chunk step. For each item the ItemReader reads, its process() method transforms or filters it, then passes the result to the ItemWriter. It is optional.

ItemReader is the input side of a chunk-oriented step. Its single method read() returns one item at a time, or null when there is no more data, signalling the end of input.

An ItemWriter is the step component that outputs processed data. Its write method receives a Chunk (a batch of items) so it can write many items in one operation, like a single batched SQL insert, which is faster than one call per item.

Spring Batch treats the same identifying parameters as the same JobInstance. If that instance already completed successfully, re-launching throws JobInstanceAlreadyCompleteException, so the job does not run again and duplicate work is avoided.

JobLauncher is the interface that starts a batch Job. You call jobLauncher.run(job, jobParameters). It returns a JobExecution describing that run (status, id, timestamps).

JobOperator is an operations-facing facade for controlling jobs — start, stop, restart, and abandon executions using simple types like job names and execution ids. JobLauncher just runs a Job you already have wired.

JobParameters are typed key/value inputs passed to a job at launch (Strings, Longs, Doubles, Dates). You build them with JobParametersBuilder and pass them to JobLauncher.run(job, params).

The JobRepository is the component that saves batch execution state to a database. It records which jobs and steps ran, their status, timestamps, and parameters, so a job can be tracked and restarted.

A JobExecutionListener lets you run code around a job. beforeJob runs before the job starts; afterJob runs once the job finishes, whether it succeeded or failed. You register it on the job builder.

On a faultTolerant() step, retry(SomeException.class) marks that exception as retryable and retryLimit(n) caps the number of attempts. Spring Batch re-runs the failing work instead of failing the job. Use it for transient errors like a brief network or DB blip.

The whole chunk's transaction rolls back, so none of the items in that chunk get written. Spring Batch wraps each chunk (read-process-write of N items) in a single transaction, so one bad item undoes the entire chunk.

Skip handling lets a step ignore individual bad items instead of failing the whole job. You enable it with faultTolerant() on the step builder, then declare which exceptions to skip and a skipLimit.

StepExecutionListener has beforeStep and afterStep callbacks that run around a single step. @BeforeStep is often put on a reader or writer method to grab the StepExecution — and through it the JobParameters — so the component can configure itself.

A multithreaded step processes chunks on several threads inside one JVM instead of one. You enable it by giving the step a TaskExecutor (e.g. step.taskExecutor(...)), so each chunk runs on a separate thread from the pool.

Partitioning splits a step's work into several named partitions that run in parallel — each processes a slice of the data (e.g. an ID range). It scales a long-running step by using multiple threads or machines.

A scaling pattern where one master step reads items and sends chunks over messaging (like a queue) to remote worker processes. The workers do the processing and writing, then reply. Reading stays central; processing/writing scales out.

Build each branch as a Flow, then call new FlowBuilder(name).split(taskExecutor).add(flowA, flowB).build(). split() supplies the thread pool, add() registers the concurrent branches, and the resulting flow becomes a step in the job.

Partitioner has one method: partition(int gridSize) returning Map<String, ExecutionContext>. Each entry is a named partition whose ExecutionContext holds that slice's parameters (e.g. minId/maxId). The worker's @StepScope reader reads them via SpEL like #{stepExecutionContext['minId']}.

Use conditional transitions on the job builder: .start(stepA).on("FAILED").to(cleanupStep).from(stepA).on("*").to(nextStep).end(). The on(...) pattern is matched against the previous step's ExitStatus to pick the next step.

A JobExecutionDecider is a small class whose decide() method returns a status that tells the job which path to take next. You use it when the choice depends on custom logic, not just whether a step passed or failed.

BatchStatus is the framework's enum (COMPLETED/FAILED/STOPPED) deciding success and restart. ExitStatus is a customizable string that flow patterns (on(...)) match on. Override ExitStatus in a StepExecutionListener's afterStep to return custom codes like "NO_DATA" and branch on them.

After a step, call .next(decider), then chain .on("NAME").to(step) for each possible status. Use .from(decider).on("OTHER").to(otherStep) to add more branches, and finish with .end().build().

FlowStep wraps a Flow and runs its steps inside the current job execution. JobStep wraps a whole Job and launches it as a separate execution with its own parameters and identity. Use FlowStep to reuse steps; use JobStep to nest an independent job.