Job scope?

[sm@h]

Could it perhaps make sence to create a JobScope? Up until now I've had no use for it, but surely there must be cases where this can be put to good use. It would just seem more consistent to me since there is already a StepScope defined.

[Dave Syer]

Good observation - at least it shows that the message about step scope is getting to the right places. In principle I would prefer not to build features that have no concrete use case. Also step scope has some of the most thorny issues in the design hanging off it, so I don't want another one to think about unless someone has a really good reason. Feel free to suggest counter arguments.

[wordywordy]

I have a concrete use case. For example, you have a job to generate banking statements to be issued in month End, say last Friday of the month. Then, at the beginning of your job, you need calculate the statement date and place in job scope for whole job to share so that every statement refers to a single statement date.

[dkaminsky]

I encourage you to comment on the JIRA issue: http://jira.springframework.org/browse/BATCH-361 with your use cases - right now it's listed as "Won't Fix" but it can be re-opened if there's enough user support.

[lucasward]

I have a concrete use case. For example, you have a job to generate banking statements to be issued in month End, say last Friday of the month. Then, at the beginning of your job, you need calculate the statement date and place in job scope for whole job to share so that every statement refers to a single statement date.

It seems like this would better be solved by putting the statement date as a JobParameter, which would then be available to all jobs, rather than a context object.

[Dave Syer]

True, but that only applies if the parameter value is known before the job starts. Sometimes it only comes from analysing the data from the fisrt step (for instance) - I had a client this week in fact with precisely this problem.

My main objection to job scoped context before was always that it doesn't make sense for it to be volatile. I was thinking, maybe a useful feature would be to carry over named properties from the ExecutionContext between steps? That way they would be persisted and always available on restart.

Even better, I like the idea of an abstraction for this so the user doesn't have to know where those things are being persisted. I think it might be too late for 1.0 for this feature, but it would be good to get some opinions now. If there is strong demand maybe we can get it into a maintenance release if it doesn't cause interface or DDL changes.