Do you use a persistent job repository?

[fmbenhassine]

The answer is most likely "it depends", but we would like to know how frequently users do actually need a persistent store for batch meta-data.

If needed, please add a comment and elaborate on your use case(s).

[scordio]

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).

[fmbenhassine]

Great! Thank you for your feedback on this.

[benelog]

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.

[benelog]

The following issue shows the limitation of ResourcelessJobRepository.

#5118

[fmbenhassine]

@benelog

The ResourcelessJobRepository is designed for a very specific use case: a single execution of a Spring Batch job. It does exactly that (and I believe it does it very well as it performs two orders of magnitude better than any other repository implementation). This is mentioned in its Javadoc as well as the reference docs. So using it for anything else than what it was designed for is incorrect.

It’s not only an issue when multiple jobs are invoked concurrently;

The Javadoc of the class and the reference docs mention that this implementation is not expected to be used in any concurrent environment:

This implementation is not thread-safe and should not be used in any concurrent environment.

you also can’t use it in a JobStep that calls another job from within a job.

Same here, this is a use case where you have two job executions: one for the outer job and one for the inner sub job.

I believe the expectations when using this class are well documented in the javadocs, reference docs and the migration guide to v6.