-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
client, kv: correctly restart the Transaction proto on DistSQL retrya…
…ble errors - pErr.GoError() now computes the Transaction that next attempts should use in case of retryable errors. This functionality moved here, some from TxnCoordSender, some from client.Txn, so that it will be at the disposal of DistSQL. The idea is that DistSQL will use this code, shared with non-DistSQL, to return to the gateway a retryable error with an updated Transaction in it. - TxnCoordSender becomes the only place that deals with restarting a Transaction. It takes the information from the error described above and sometimes calls Transaction.Restart(). The role of the client.Txn is reduced, and restarting-like things are consolidated in the TxnCoordSender. In the non-DistSQL world, the flow of a retryable txn becomes: - storage returns a retryable error such as TransactionRetryError or TransactionRestartedError. These are ErrorDetails in a pErr, and pErr.TransactionRestart != NONE identifies them. - TxnCoordSender.Send() gets these errors, calls pErr.GoError(). This returns an InternalRetryableTxnError, with an updated Transaction in it. - TxnCoordSender performs Transaction.Restart(). It then puts the restarted Transaction in a HandledRetryableError. This error is an ErrorDetail, and it's used for the TxnCoordSender to communicate with the client.Txn.Send() through the Sender interface. The restarted txn is also copied to its map of ongoing transactions. This way, the map is kept in sync with the Transaction that the client.Txn will use. - client.Txn now only deals with HandledRetryableError's, in terms of retryable errors. How it handles them is straight-forward: it copies the Transaction from them to its copy of the Proto (this is the proto that will be used for all future requests. Still TBD is exactly what DistSQL is going to do. The gateway will have a side-channel through client.Txn into TxnCoordSender to ask it to update its state. But for this it needs an InternalRetryableTxnError. I think we'll need to have DistSQL execution on remote nodes bypass the TxnCoordSender on those node, so that the InternalRetryableTxnError is not transformed into a HandledRetryableError.
- Loading branch information
1 parent
50a1ada
commit 5d89c15
Showing
25 changed files
with
1,360 additions
and
629 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.