Since 1.0 came out we have been pushing users to understand that JobInstance = Job + JobParameters. For the most part, I think people understand the relationship. The one issue that has been brought up a few times is how they manage the changing job parameters in order to create a new instance. We've used the 'get current time' approach to always give a new instance, but this isn't really something that works well in production. (Although it's a great testing approach). I've been working with a few clients and the problem of managing parameters seem to always be pushed off at some level to be handled by the client of JobLauncher. At one client, they create a separate table similar to our JobParameters table that kept track of their parameters and dates. We have always encouraged this because the framework has absolutely no idea what makes one instance different from another. However, we're pushing an awful lot of work onto users. The use case below is an example of something I have to build for a client that illustrates the problem:

This particular application needs to check a schedule setup by users of an online application, to determine when certain files are to be uploaded into the system. For this reason, it's imperative that the daily batch job knows exactly which day it's running for. For example, if run on monday, the job may find and schedule 10 files to be uploaded for that day. On Tuesday, it will likely find an entirely different set of files. The days in which these files are loaded is important for the system.

It's not a particularly difficult problem to solve. Generally speaking, it should be solved using the 'Schedule Date' pattern. This pattern indicates that a job is started and identified by a schedule date that determines the data in which the job will be operating on. For example, using the job above, if there is a catastrophic error on monday and the job cannot be run until tuesday. The job will be run with a schedule date of monday, even though the day it's being run on is Tuesday, thus ensuring the files that should have been loaded on monday eventually get loaded. It's a fairly common batch pattern that's been around for a very long time. To implement it with Spring Batch, I need to create a separate set of tables outside of the architecture, or require the scheduler itself to keep track of it. (some do). If I was to create tables, I would need to check the tables to see the last schedule date that was run successfully, and increment it, then store the fact that it was incremented. Once the job returns, I need to flip that record back to indicate that it finished successfully. There's also a few potential error scenarios that must be thought of. For example, some type of error that happens between the launcher returning and this wrapper writing out the status change. It's not a particularly hard problem to solve. I could easily catch a JobInstanceAlreadyCompleteException to help handle this scenario. However, it's a lot to ask of developers, and I know many might have issues handling the error scenarios correctly.

What I would like to propose is that the framework simply tell the developer when they need to 'increment' the parameters. Part of the reason why we have always pushed this responsibility to outside the framework is because we have no way of knowing how they want them to be incremented and under what circumstances. For example, we can't assume a date should be incremented by one day. There could be many scenarios when it should be incremented by an entire week. In other cases, certain parameters may need to stay constant for the most part. In my opinion, the solution to this problem is to simply provide a hook for users to tell us how parameters should be incremented. The interface would look something like the following:

public void JobParametersIncrementer{

  JobParameters incrementParameters(JobParameters jobParameters);
}

The solution for my use case above would be the following:

JobParameters incrementParameters(JobParameters jobParameters){
  return new JobParametersBuilder().addString(incrementDate(jobParameters.getString(scheduleDate)));
}

We could probably even provide a new constructor for the builder that takes an existing parameters, so that only the one parameter that needs to change could be incremented.

I'm not sure where exactly this would belong in the API, it seems like the JobLauncher could take it as a parameter. If the JobRepository returns that the job is already complete, the launcher could call the incrementer, then try and create an execution again. (possibly using a configuration option to determine if it should try) If there's an issue the second time it could fail, if not it should run as normal. This would allow the framework to manage the task of checking for completion, but allow the user to determine how the parameters should be changed as a result.