Replica's log is ahead of the current Master, and in this case, the Replica was unable to rollback without a recovery. As a consequence, it is possible that one or more of the most recently committed transactions may need to be rolled back, before the Replica can synchronize its state with that of the current Master. Note that any CommitTokens obtained before restarting this Replica shouldn't be used after {@link RollbackException}is thrown because the token may no longer exist on the current Master node, due to failover processing. Existing {@link ReplicatedEnvironment}, and consequently {@link Database}handles, are invalidated as a result of this exception. The application must close all old handles and create new handles before it can proceed. The actual rollback of any recently committed transactions is done when the application re-instantiates and thereby reopens the {@link ReplicatedEnvironment}. The application is responsible for discarding and recreating any transient state that may be associated with the committed transactions that were rolled back. {@link #getEarliestTransactionId} and {@link #getEarliestTransactionCommitTime} provide information to helpdetermine which transactions might be rolled back. Note that it is possible that no committed transactions have been rolled back and that the application need do no adjustments, in which case {@link #getEarliestTransactionCommitTime} will return null.
This exception should be encountered relatively infrequently in practice, since the election mechanism favors nodes with the most advanced log when deciding upon a master. The exception, due to its nature, can only be encountered when the node is in the Replica state, or the node is trying to transition to the Replica state.
Use of weak durability requirements like {@link com.sleepycat.je.Durability.ReplicaAckPolicy#NONE} or a{@link com.sleepycat.je.rep.ReplicationMutableConfig#NODE_PRIORITY} of zeroincreases the likelihood of this exception. @see RollbackProhibitedException
| |
| |