Bug 4536

Summary: PartitionReducer seems redundant
Product: jbatch Reporter: mminella
Component: sourceAssignee: cvignola
Status: RESOLVED WORKSFORME    
Severity: major CC: issues
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description mminella 2013-01-17 16:19:12 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?
Comment 1 cvignola 2013-01-17 17:50:26 UTC
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.
Comment 2 cvignola 2013-02-01 23:51:36 UTC
My present intention is to keep PartitionReducer in the spec because of its specialization for partition processing.