Conversation
|
Reviewed 3 of 3 files at r1, 7 of 7 files at r2, 1 of 1 files at r3, 1 of 1 files at r4, 5 of 5 files at r5, 6 of 6 files at r6, 1 of 1 files at r7, 8 of 8 files at r8, 12 of 12 files at r9, 21 of 21 files at r10. client/db_internal_test.go, line 37 [r10] (raw file): kv/txn_coord_sender.go, line 304 [r10] (raw file): roachpb/batch.go, line 262 [r10] (raw file): storage/client_split_test.go, line 304 [r5] (raw file): storage/client_split_test.go, line 315 [r5] (raw file): storage/engine/rocksdb/db.cc, line 186 [r2] (raw file): storage/replica.go, line 1108 [r5] (raw file): storage/replica.go, line 143 [r10] (raw file): storage/replica_test.go, line 1513 [r9] (raw file): storage/response_cache.go, line 174 [r5] (raw file): storage/response_cache.go, line 77 [r9] (raw file): storage/response_cache.go, line 91 [r9] (raw file): Comments from the review on Reviewable.io |
storage/replica.go
Outdated
There was a problem hiding this comment.
Now that cmdIDKeys are not used as rocksdb keys, I don't think we need to have a time prefix. They can just be random.
|
LGTM |
|
So much code deletion! Review status: all files reviewed at latest revision, 5 unresolved discussions. storage/replica.go, line 907 [r10] (raw file): Comments from the review on Reviewable.io |
|
Review status: all files reviewed at latest revision, 5 unresolved discussions, some commit checks failed. kv/txn_coord_sender.go, line 304 [r10] (raw file): storage/replica.go, line 1108 [r5] (raw file): storage/replica.go, line 143 [r10] (raw file): storage/replica_test.go, line 1513 [r9] (raw file): Comments from the review on Reviewable.io |
|
added some commits addressing comments, PTAL. |
|
Reviewed 12 of 12 files at r11, 3 of 3 files at r12, 3 of 3 files at r13, 1 of 1 files at r14. roachpb/api.go, line 54 [r13] (raw file): roachpb/api.go, line 506 [r13] (raw file): Comments from the review on Reviewable.io |
|
Review status: all files reviewed at latest revision, 3 unresolved discussions. storage/replica.go, line 907 [r10] (raw file): I'm not sure if it's safe to make this a per- Comments from the review on Reviewable.io |
|
Review status: all files reviewed at latest revision, 2 unresolved discussions. roachpb/api.go, line 54 [r13] (raw file): Comments from the review on Reviewable.io |
|
PTAL baby one more time |
|
LGTM |
|
Reviewed 4 of 4 files at r15. Comments from the review on Reviewable.io |
|
Review status: all files reviewed at latest revision, 1 unresolved discussion. storage/replica.go, line 907 [r10] (raw file): Comments from the review on Reviewable.io |
in the near future, command IDs will be linked to transaction IDs, so the transaction GC can take care of them.
due to the cached error, that's an infinite loop. see cockroachdb#3067
* the response cache now contains only a sentinel, no actual data * on a cache hit, returns a TransactionRetryError to the client closes cockroachdb#2297 (since we simply have the transaction retry, we don't have to worry about assembling the correct response).
old key schema: /prefix/<cmd_id> -> <response> new key schema: /prefix/<txn_id> -> <sequence_id> on a cache hit, if stored sequence_id >= txn.Sequence, return TransactionRetryError. txn.Sequence increases when retrying at the Store level, and when sending a new chunk of batch.
removes
roachpb.ClientCmdIDand replay protection for non-transactional commands.Instead, transactional commands are now cached on a per-ID response cache key. The cached value is the newly introduced sequence number which is increased whenever a new request is sent as part of the transaction (in particular, in
client,DistSender's chunking sender and beforeStore-level retries).Whenever a request encounters a cached sequence number greater than or equal to the transaction's, a
TransactionRetryErroris the result; the client will back of and come again.In particular this fixes #2297 (since we don't return results, but simply an error) and #626 (since the response cache entries are now in 1:1 correspondence to transaction table entries, so #2062 is now the relevant issue covering this).
Commit-by-commit reviewing is suggested, though a casual look through the commit history probably makes sense to avoid comments invalidated by later changes.