What class name should we use for the unit of work?

[gmatthews]

I guess having definite hierarchy levels is ok if you assume that TaskLet, Chunk, Step, etc, are going to be delegating to Spring services, and that each time you want to create a new batch job, you're going to be creating new TaskLet, Step, Job, etc, implementations.

For example,

Batch Job A might have a Step that delegates to Spring Services X and Y, whereas Batch Job B might have a Step that delegates to Spring Service X only.

In this case, the different Step implementations in Batch Jobs A and B are little more than wrappers that allow correct handling of transactions.

If the expectation was that each Job or Step implementation was going to contain any real logic, then I'd stick by my point that the Spring Batch team choosing an interfaces approach to allow definition of where steps begin was still a bad idea IMO -- and that the "everything is a (nested) Job" and "use annotations or Spring configuration to control transaction/retry demarcation" is a more flexible.

So, another question...how does the @Transactional annotation fit into Spring Batch?

[Dave Syer]

The low-level infrastructure components that I blogged about (http://blog.interface21.com/main/200.../spring-batch/) provide the "everything is a (nested) Job" and "use annotations or Spring configuration to control transaction/retry demarcation" features that you mention. I expect them to be quite valuable in a range of optimisation situations. And @Transactional fits into that world in the same way it fits into any other Spring application.

Job/Step/Tasklet are higher level domain concepts, where the value the framework is adding is more to do with reporting, management (lanching, stopping, etc.) and monitoring specific job executions. They do a little more than correctly handle transactions, but if that stuff isn't valuable to you then the infrastructure is available. Or we'd be happy to consider new use cases for the framework.