Spring Boot 4 Batch JDBC starter: verify that job history is actually stored

Inspect the repository, not its surroundings

A file-backed DataSource can coexist with an in-memory Batch repository. Both JVMs might print JobInstance ID 1 simply because each started a fresh repository. That is not restart. The source kit now uses the Boot 4 JDBC Batch starter and checks the BATCH_JOB_INSTANCE and BATCH_JOB_EXECUTION tables after two runs: one instance, two executions. The recorded-failure test checks the same persisted identity across process boundaries.

Keep the schema on the same database

The first test launch initializes Batch metadata in the H2 file; the second launch does not recreate that schema. Business rows and Batch metadata use the same local DataSource. This is a fixture choice. A deployed service may use a separate repository database, but the job must connect to the same durable repository on every attempt. Check the actual configured JobRepository bean and schema before relying on restart.

Guard the production claim

A resourceless repository is valid for jobs that do not need restart history. It is wrong for a job advertised as resumable. A row count of four after two processes proves neither persistence nor a single JobInstance when the writer uses an upsert. Inspect metadata directly and try an abrupt-death case as the checked recovery test does.

Checked excerpt

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-batch-jdbc</artifactId>
</dependency>

Cost and verification

JDBC job metadata adds writes around launches, steps and commits. Retain and back up its tables under a policy tied to audit and restart needs.

Common Mistakes

• Do not infer a JDBC JobRepository from the presence of JdbcTemplate.
• Do not treat matching auto-generated IDs in separate empty repositories as proof of a restart.
• Do not initialize Batch metadata anew on every retry.

Read next

Spring Batch restart across two JVMs after a recorded failed execution, Spring Batch killed worker: fence it, recover STARTED, then restart, Spring Batch job identity: a manifest ID defines restart versus a new run, Spring Batch restart test matrix: separate failure, process loss and changed input.