Neustartfähigkeit & Fehlertoleranz

The whole point of a batch framework is surviving failure. Two mechanisms deliver that: restartability - the JobRepository remembers how far a job got, so a failed run resumes instead of starting over - and fault tolerance - skip and retry policies let a single bad record be tolerated without aborting a multi-hour job.

Restart: the JobRepository remembers

Every chunk commit updates the JobRepository (a set of Spring Batch tables in your database) with the step's position. So if BookVault's import dies at record 1,900,000, the repository already recorded the 1,899,900 successfully committed. Re-launching the same JobInstance (same job parameters) resumes from where it stopped:

JobParameters params = new JobParametersBuilder()
    .addString("reportDate", "2026-07-22")   // identifies the JobInstance
    .toJobParameters();

jobLauncher.run(overdueReportJob, params);   // first run fails at chunk 19,001
// ... fix the problem, launch again with the SAME params ...
jobLauncher.run(overdueReportJob, params);   // resumes at chunk 19,001, not chunk 1

The rule that makes this work: job parameters identify the instance. Same parameters = same JobInstance = resume. Different parameters (e.g. a new reportDate) = a brand-new instance that starts fresh. This is why a completed instance can't be re-run with identical parameters - Spring Batch refuses, because it already finished.

Skip: tolerate bad records

By default, one exception aborts the step. A skip policy says "these exceptions on a single item are survivable - log it and move on":

@Bean
Step importStep(JobRepository repo, PlatformTransactionManager tx,
                ItemReader<RawBook> reader, ItemWriter<CatalogEntry> writer) {
    return new StepBuilder("importStep", repo)
        .<RawBook, CatalogEntry>chunk(100, tx)
        .reader(reader).writer(writer)
        .faultTolerant()
        .skip(FlatFileParseException.class)   // a malformed CSV line...
        .skipLimit(50)                        // ...tolerate up to 50, then fail the job
        .build();
}

Now a malformed row is recorded as skipped and the run continues - up to skipLimit, after which Spring Batch concludes the input is too broken and fails the job. Skips are counted in the StepExecution so you can report "processed 1,000,000, skipped 37".

Retry: survive transient failures

Some failures aren't the record's fault - a deadlock, a brief network blip to a downstream service. Retry re-attempts the operation before giving up:

        .faultTolerant()
        .retry(TransientDataAccessException.class)   // e.g. a lock timeout
        .retryLimit(3)                               // try up to 3 times
        .skip(TransientDataAccessException.class)    // if still failing, skip it
        .skipLimit(10)

Retry and skip compose: retry a flaky operation a few times, and if it still fails, skip that item rather than abort. The distinction matters - retry is for transient errors that might succeed on a second try; skip is for permanent bad data that never will.