Bug 4536 - PartitionReducer seems redundant
PartitionReducer seems redundant
Product: jbatch
Classification: Unclassified
Component: source
All All
: P5 major
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2013-01-17 16:19 UTC by mminella
Modified: 2013-02-01 23:51 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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.