Bug 4767 - SPEC - Checkpoint Algorithm interface issues
SPEC - Checkpoint Algorithm interface issues
Product: jbatch
Classification: Unclassified
Component: source
All All
: P5 normal
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2013-03-11 19:11 UTC by mminella
Modified: 2013-03-11 19:55 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-03-11 19:11:58 UTC
1.  the checkpointTimeout returns an int currently.  If we end up supporting in any way milliseconds, I'd assume that this would change to a long.
2.  Why does the checkpointTimeout method exist at all?  I would expect all state required to manage the checkpoint to be maintained within the implementation of the CheckpointAlgorithm implementation (so beginCheckpoint takes the current timestamp and isReadyToCheckpoint checks against that.  There is no need to expose that timeout value).
3.  What does the endCheckpoint() method bring to the table? In SB, we have essentially three methods in our CompletionPolicy: isComplete (isReadyToCheckpoint), start (beginCheckpoint), and update (no equivalent).  The update is called once per item so that the state of the implementation can be updated.
Comment 1 cvignola 2013-03-11 19:55:36 UTC
1) int checkpointTimeout()

int max value is 2**31-1/1000millis/60sec/60/min/24hr ~ 24 days.  That's a long time for a single checkpoint.  If it were critical to change the return type and code was not written, time short, I'd be happy to change.  However, given where we are, I think nothing substantive is at risk by retaining the current return type.

2) what checkpointTimeout() for anyway?  

The purpose is to provide a flexible means for establishing the checkpoint time - e.g autonomic.  The runtime uses it to set the UserTransaction timeout.  

3) what is endCheckpoint for?   

beginCheckpoint/endCheckpoint are essentially beforeCompletion/afterCompletion for the checkpoint transaction.