Jobs, Steps, and the JobRepository Model
Structure batch workloads with jobs, steps, and metadata persistence for execution tracking.
Why Spring Batch Exists
Many real-world workloads are not request/response: nightly invoice generation, CSV imports, report exports, data migrations. These run as batch jobs processing large volumes of records.
- They must be restartable after a crash.
- They must track progress so you know what already ran.
- They must handle millions of rows without loading everything into memory.
Spring Batch gives you a structured model for exactly this. The three core abstractions you must understand first are the Job, the Step, and the JobRepository.
The Job: A Unit of Work
A Job is the top-level container for an entire batch process. It has a name and is composed of one or more ordered Step instances.
- One
Jobdefinition can be executed many times — each run is a JobInstance. - Each attempt at running a JobInstance is a JobExecution (status, start time, exit code).
In Spring Boot 4 you build a Job with a JobBuilder, supplying a name and a JobRepository.
@Bean
public Job importInvoicesJob(JobRepository jobRepository, Step readStep) {
return new JobBuilder("importInvoicesJob", jobRepository)
.start(readStep)
.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