spring-batch

Spring Batch development

Every rule here was paid for. Where a claim has a measurement or a runnable sample behind it, the source is named — prefer checking it over trusting this file, and correct the file when it is wrong (see Growing this skill).

Ground new behaviour in the playground first. spring-boot-playground's spring-boot-batch-parent/ holds one module per mechanism, each asserting behaviour rather than describing it: spring-boot-batch-restart, -flow, -tasklet, -partition. When you are unsure what the framework does, write the case there and run it — that is what the modules are for (use a local checkout if one exists; otherwise clone the repo). 17 tests, H2, no external services.

---

1. The default JobRepository stores nothing, and that is deliberate

The single most expensive thing to not know.

spring-boot-starter-batch plus a working DataSource yields ResourcelessJobRepository. There is no BatchJdbcAutoConfiguration in Boot 4's batch module — all eleven classes of org.springframework.boot.batch.autoconfigure were checked.

It is a design decision, not an omission. whatsnew.html: it has been the default since 5.2, "no longer requires an in-memory database (H2, HSQLDB) for metadata storage", which "improves default performance and reduces memory footprint". Knowing that changes how you argue about it: the framework is not broken, it is optimised for the case where nobody restarts anything, and it does not tell you which case you are in.

What that looks like: the job runs, every step executes, it reports COMPLETED, and nothing is written down. Every execution comes back id 1, no BATCH_* table is created, and restart does not exist — not refused, absent. Nothing warns you.

scan=d-1 execId=1 jobInstanceId=1
scan=d-2 execId=1 jobInstanceId=1      <- two different runs, same ids
tables: []
repository impl: ResourcelessJobRepository