It is safe to run out of the box because no threading is done. Where is the dependency on WorkManager by the way? I assume it is only in JavaDocs because we delegate all threading concerns to the Spring TaskExecutor. There are issues with restartability when you use concurrent execution, but some jobs do not require that. After 1.0 we plan to address that more generally.
Originally Posted by rotis23
I think of it as like a controller or action in a presentation tier - i.e. above the service layer. Business delegate pattern is definitely recommended when implementing ItemProcessor.
- What is the ideal work scope of the tasklet? Is seems better design to have lots of small 'steps' but what if the business code is quite complex and requires lots of data processing? Should these be encapsulated into a separate 'service'?
No, and yes, in that order. A rules processing engine would be trivial to integrate with Spring Modules, so we might not do anything concrete in Spring Batch. Let us know if there is anything awkward that you think ought to be provided natively.
- Has there been any work into integrating third party rules processing engines (e.g. Drools,JRules)? Is that best placed within the tasklet/processor code?
Same answer! But actually the details depend pretty heavily on what you wanted to do with the data cache.
- Has there been any work into integrating third party data cache solutions (e.g. Tangosol)? Again, is that best placed within the tasklet/processor code?
Not right now - we had that feature in an early unreleased version actually, and we decided it wasn't adding enough value. If you pass state between steps in memory you also need to persist it in case there is a failure and a restart, so actually there isn't much benefit without some cleverness. It might be worth the effort to look at it again at some point.
- Is there a method of passing a business data model in memory between steps?
BatchResourceFactoryBean is the standard way of doing that. It is something we are discussing internally a lot at the minute so if you have any observations or suggestions we'd be quite pleased to get some input. I am particularly keen to retain the traceability of the JobIdentifier - you shouln't be able to simply run a job twice with different parameters and not be able to tell the differences later in some sort of persistent storage (audit trails). See also http://opensource.atlassian.com/proj...rowse/BATCH-84.
- (I think this question has been asked on this list before but it was a while ago so apologies for asking it again!) Is there a method of passing runtime information from the job script to the input/output sources? I'm thinking particularly of how to specify what files to process or date constraints etc.