I'm new to Spring Batch, so forgive any incorrect assumptions I may have.

Just wondering, what was the thinking behind preventing users from running the same job more than once with the same set of parameters (which would throw a JobInstanceAlreadyCompleteException)? Was the goal to prevent, say, a nightly job from accidentally executing twice? Or if jobs were kicked off in async threads, to prevent overlapping jobs?

I'm designing a system that syncs one database to a different target database. This sync could be incremental, it could a full sync, or specific records, all based on a trigger file. It is possible this system might be running on 2+ servers in case we needed to run tasks in parallel.

I envisioned a single sync job which would be instantiated based on the sync-type parameters. At first I was thinking of using startNextInstance and using an incrementer to ensure job parameter uniqueness. For example, if you started a job on one machine, and then started the same job on another, you would be guaranteed a different run.id. But then I realized you can't pass in other parameters when you use startNextInstance(), which I believe is the only operation that uses the incrementer.

But in order to use start() which allows parameters, but doesn't use the incrementer, I have to pass in something like a timestamp in order to ensure job parameter uniqueness, which seems like a bit of a hack.

I don't really like the idea of having to define a separate job for each possible parameters combination. Also, the idea of restarting those executions over and over again and never getting an exit status of COMPLETED is kind of bothersome.

The solution I'm considering is keeping my owner parameters table with each record containing a unique identifier, and passing that identifier to my job as the parameter. That way a job always has a unique parameter that is being consistently incremented, and I can still pass in parameters.

Still, I would figure this would have been possible with just the framework. Like a version of startNextInstance which allows you to use an incrementer yet still takes in new parameters.