Bugzilla – Bug 4536
PartitionReducer seems redundant
Last modified: 2013-02-01 23:51:36 UTC
Since the PartitionReducer is only executed at the beginning and end of a step (just happens to only be used in a partitioned step), why can this functionality not be handled with a regular StepListener? What is the difference in execution between this and a StepListener?
The key role of the reducer is to facilitate control of completion/compensation logic for a partitioned step. It receive control for things like:
1) partitions complete/step is rolling back
2) partitions not started/step is restarting
3) partitions are complete
I concede all these things could be discerned in the StepListener.
The only other difference is that as currently defined in the spec, StepListener methods do not get invoked in the scope of a global tran (see section 8.6), while reducer methods do. That could be important for executing compensation logic against multiple transactional resource managers. Of course, a StepListener could manage its own tran if necessary.
So I suppose the best we could say about PartitionReducer is it is a fit-for-purpose interface that (in a sense) specializes what could be accomplished in a less obvious way via StepListener.
So I suppose we could eliminate PartitionReducer in the interest of a leaner programming model or keep it for the value of its specialization.
I think I could be persuaded either way.
My present intention is to keep PartitionReducer in the spec because of its specialization for partition processing.