Fault Tolerance, Skip, and Retry Policies
Configure skip, retry, and restart semantics to make jobs resilient to transient data errors.
Why Fault Tolerance Matters
Batch jobs process huge volumes of data, and real-world data is messy. A single malformed row, a momentary database deadlock, or a flaky downstream call can blow up a job that has already processed millions of records.
Spring Batch gives a chunk-oriented step fault tolerance so it can survive these issues without aborting the whole run. The three core tools are:
- Skip — discard records that cause unrecoverable errors (e.g. bad data) and keep going.
- Retry — re-attempt an operation that failed due to a transient error (e.g. a lock timeout).
- Restart — resume a failed job instance from where it stopped instead of starting over.
Used together, these turn a brittle job into a resilient one.
Enabling Fault Tolerance on a Step
Fault tolerance is opt-in. When you build a chunk step, call .faultTolerant() on the step builder to switch to the fault-tolerant variant. Only then can you declare skip and retry rules.
Without .faultTolerant(), any exception thrown by a reader, processor, or writer rolls back the chunk and fails the step immediately.
@Bean
public Step importStep(JobRepository jobRepository,
PlatformTransactionManager txManager,
ItemReader<Customer> reader,
ItemProcessor<Customer, Customer> processor,
ItemWriter<Customer> writer) {
return new StepBuilder("importStep", jobRepository)
.<Customer, Customer>chunk(100, txManager)
.reader(reader)
.processor(processor)
.writer(writer)
.faultTolerant() // unlocks skip & retry configuration
.build();
}All lessons in this course
- Jobs, Steps, and the JobRepository Model
- Chunk-Oriented Reader-Processor-Writer Flows
- Fault Tolerance, Skip, and Retry Policies
- Partitioning and Parallel Step Execution