Make commit_unknown_results unlikely - PR status

[rajivr (Rajiv M Ranganath)]

@andrew.noyes

A commit that fails with transaction_timed_out is still in-flight, so it could commit after you read the sentinel key.

Thanks a lot for mentioning the issue with transaction_timed_out. I completely forgot about it!

You had also mentioned the following in a previous thread.

@andrew.noyes

For transaction_timed_out this isn’t so bad, as the default retry loop (i.e. on_error) does not consider transaction_timed_out to be retryable. It does however consider cluster_version_changed to be retryable.

Are there any other error codes similar to cluster_version_changed that has the behavior of being retryable while the transaction is still in-flight?

In order to correctly deal with in-flight transactions for non-idempotent transactions, would the following mechanism work?

1. In the event we receive a transaction_timed_out or cluster_version_changed, wait for a specific duration of time, for example 10 seconds.

2. The in-flight transaction would have, by this time, either been committed, or the transaction would have been rejected due to the 5 second limit.

3. After 10 seconds, attempt to read the sentinel key again. This time if we are able to read the sentinel key, that would mean a successful commit. Missing sentinel key would mean the previous transaction failed to commit and would also not commit in the future.

@andrew.noyes

Also maybe I missed it but I don’t think the doc mentions what happens if the sentinel key could have been garbage-collected when you read it.

That would be an error in the garbage collection algorithm. For the design to work correctly, the garbage collection process must leave a threshold (for example: 72 hours) of sentinel keys untouched.

I’ve updated the document reflect this (Tracking is now enabled, so you can easily find the edit).