We have use cases where a Spring Batch job is implemented as a command line application (e.g., a Spring Boot executable JAR), and such an application is scheduled on Unix via cron on at least two servers, with a delta between each schedule.

As all application executions share the same database for batch metadata, we can ensure that the corresponding job runs at most once (given that the same identifying parameters are provided), and is also tolerant to failures or planned downtime.

We also have other use cases where batch metadata is not relevant, and such applications/jobs run as command-line applications, but with an in-memory database like H2 (we will migrate to the ResourcelessJobRepository in the future).

Because of its constraints, ResourcelessJobRepository often ends up being unusable, and I hope that can be improved. It’s not only an issue when multiple jobs are invoked concurrently; you also can’t use it in a JobStep that calls another job from within a job.

Although it had similar concurrency issues, in terms of applicability (scope of use), I feel the older MapJobRepository was better.