Bugzilla – Bug 4767
SPEC - Checkpoint Algorithm interface issues
Last modified: 2013-03-11 19:55:36 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.
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.