Jobs, Steps & Chunks

A Spring Batch Job is the unit you launch. Inside, it's a sequence of Steps, and the workhorse step is chunk-oriented: it reads items one at a time, processes each, and writes them out in fixed-size chunks - each chunk wrapped in its own transaction. That structure is the whole reason batch scales, so let's build the mental model precisely.

Job → Steps → Chunks

A Job is a named, restartable process. It's composed of one or more Steps run in order (or branching on success/failure). Each Step does one phase of work. For BookVault's nightly report, the Job might be:

• Step 1 - read active loans, keep the overdue ones, write report rows to a staging table.
• Step 2 - read staged rows grouped by member, email each member their summary.

Within a chunk-oriented Step, work flows as read → process → write, batched:

@Bean
Job overdueReportJob(JobRepository repo, Step reportStep) {
    return new JobBuilder("overdueReportJob", repo)
        .start(reportStep)          // step 1; .next(emailStep) would chain step 2
        .build();
}

@Bean
Step reportStep(JobRepository repo, PlatformTransactionManager tx,
                ItemReader<Loan> reader, ItemProcessor<Loan, ReportRow> processor,
                ItemWriter<ReportRow> writer) {
    return new StepBuilder("reportStep", repo)
        .<Loan, ReportRow>chunk(100, tx)   // 100 items per transaction
        .reader(reader)
        .processor(processor)
        .writer(writer)
        .build();
}

The chunk is a transaction boundary

The magic number chunk(100, tx) means: read 100 items (one at a time), process each, then hand the whole batch of 100 to the writer once, and commit. Then the next 100. This is the key idea:

• Bounded memory - only 100 items are in flight, never the whole 2-million-row dataset.
• Incremental durability - each chunk commits independently. If the job dies at record 1,900,050, the 1,900,000 records in already-committed chunks are safe.
• Efficient writes - the writer receives a List of 100, so it can do one batched INSERT instead of 100 round-trips.

read read read ... (×100) → process each → writer.write(List<100>) → COMMIT
read read read ... (×100) → process each → writer.write(List<100>) → COMMIT
...

JobInstance, JobExecution, StepExecution

Spring Batch records every run in the JobRepository with three concepts worth knowing:

• JobInstance - a logical run identified by its job parameters (e.g. reportDate=2026-07-22). The same parameters = the same instance.
• JobExecution - one attempt at a JobInstance. If Monday's run fails and you restart it, that's a second JobExecution of the same JobInstance.
• StepExecution - one attempt at a Step, tracking read/write/skip counts and the commit position.

This is what makes restart work: the JobRepository knows a given JobInstance's last position, so a restart resumes instead of starting fresh (next lesson).