Spring Batch Job Parameters and Restarting Failed Jobs

Q: Spring Batch Job Parameters and Restarting Failed Jobs

**Job parameters** uniquely identify a `JobInstance` — the same Job name plus the same parameters always map to the same instance, preventing duplicate runs. When a job fails, its `JobExecution` is marked `FAILED` in the JobRepository, and re-launching with the same parameters triggers a **restart** that skips already-committed steps and resumes from the last failed or incomplete step. The reader's position (saved in `ExecutionContext` as `read_count`) is the checkpoint — `FlatFileItemReader` seeks forward by line count, paging readers skip by offset, and partitioned jobs restart only the failed partitions.

Intermediate·2 min read·

IBMCognizantSAPOracleSociete Generale

Fast recall

Quick revision

Core answer

Job parameters uniquely identify a JobInstance — the same Job name plus the same parameters always map to the same instance, preventing duplicate runs. When a job fails, its JobExecution is marked FAILED in the JobRepository, and re-launching with the same parameters triggers a restart that skips already-committed steps and resumes from the last failed or incomplete step. The reader's position (saved in ExecutionContext as read_count) is the checkpoint — FlatFileItemReader seeks forward by line count, paging readers skip by offset, and partitioned jobs restart only the failed partitions.

Interview-ready guide

Interview answer

Spring Batch's restart capability is one of its most powerful features — a job that fails at record 50,000 can resume from record 50,001 rather than starting over. This requires understanding how parameters, instances, and executions relate.

The identity model:

JobInstance = Job name + JobParameters; represents a logical run
JobExecution = one physical attempt of a JobInstance; a failed JobInstance gets a new JobExecution on restart
StepExecution = one attempt of one step; stores read_count, write_count, commit_count, plus the ExecutionContext for restart state

Starting vs restarting:

First run: jobLauncher.run(job, params) creates a new JobInstance and JobExecution
Restart: same parameters find the existing FAILED JobInstance and create a new JobExecution; completed steps are skipped
A COMPLETED JobInstance cannot be re-launched by default — use allowStartIfComplete(true) per step if needed

Late binding with `@StepScope`:

@StepScope @Bean FlatFileItemReader reader(@Value("#{jobParameters['inputFile']}") String file)
The file value is not available at context load time; @StepScope defers bean creation until the step starts
Essential for parameterized readers and writers

Parameter design:

Business parameters are identity (processingDate, region)
Technical parameters are additive (run.id from RunIdIncrementer)
Conflating them — like UUID on every launch — defeats restart entirely

In an interview, I'd emphasize the JobInstance vs JobExecution distinction and the late binding via @StepScope — both are common gotchas that signal production experience.

03 · Deep dive