- All Implemented Interfaces:
- RequestCallback<org.apache.cassandra.service.paxos.PaxosPrepare.Response>, RequestCallbackWithFailure<org.apache.cassandra.service.paxos.PaxosPrepare.Response>, Paxos.Async<org.apache.cassandra.service.paxos.PaxosPrepare.Status>
public class PaxosPrepare
extends PaxosRequestCallback<org.apache.cassandra.service.paxos.PaxosPrepare.Response>
implements Paxos.Async<org.apache.cassandra.service.paxos.PaxosPrepare.Status>
Perform one paxos "prepare" attempt, with various optimisations.
The prepare step entails asking for a quorum of nodes to promise to accept our later proposal. It can
yield one of five logical answers:
1) Success - we have received a quorum of promises, and we know that a quorum of nodes
witnessed the prior round's commit (if any)
2) Timeout - we have not received enough responses at all before our deadline passed
3) Failure - we have received too many explicit failures to succeed
4) Superseded - we have been informed of a later ballot that has been promised
5) FoundInProgress - we have been informed of an earlier promise that has been accepted
Success hinges on two distinct criteria being met, as the quorum of promises may not guarantee a quorum of
witnesses of the prior round's commit. We track this separately by recording those nodes that have witnessed
the prior round's commit. On receiving a quorum of promises, we submit the prior round's commit to any promisers
that had not witnessed it, while continuing to wait for responses to our original request: as soon as we hear of
a quorum that have witnessed it, either by our refresh request or by responses to the original request, we yield Success.
Success is also accompanied by a quorum of read responses, avoiding another round-trip to obtain this result.
This operation may be started either with a solo Prepare command, or with a prefixed Commit command.
If we are completing an in-progress round we previously discovered, we save another round-trip by committing and
preparing simultaneously.