[KeyValueSnapshotReader Phase II] Part 9: Introducing KeyValueSnapshotReader #7076
Conversation
| @@ -1615,7 +1568,7 @@ private <T> ListenableFuture<Collection<Map.Entry<Cell, T>>> getWithPostFilterin | |||
| + " or in the very rare case, could be due to transactions which constantly " | |||
| + "conflict but never commit. These values will be cleaned up eventually, but" | |||
| + " if the issue persists, ensure that sweep is caught up.", | |||
| SafeArg.of("table", tableReference), | |||
| * | ||
| * @return false if we cannot roll back the failed transactions because someone beat us to it | ||
| */ | ||
| private boolean rollbackFailedTransactions( |
There was a problem hiding this comment.
What's your longer term plan for this class? Do you intend to keep rollback e.t.c in this class, or move it out to some other new abstraction?
There was a problem hiding this comment.
Also, do you plan on eventually moving tests from SnapshotTransaction that are relevant to this class into a test class just for KVSR?
There was a problem hiding this comment.
A q for duplication - do you want to leave a TODO here? Unless you've already prepared the work for it.
There was a problem hiding this comment.
Yeah the only other piece planned for this one was for something that handles rollbackFailedTransactions(...) to be extracted (it's used by both the "commit writes" piece of SnapTrans for aborted things found during conflict checking, and as part of reads here).
There was a problem hiding this comment.
The tests thing could be useful, though dependent on bandwidth 😬
|
Released 0.1094.0 |
General
Before this PR:
KeyValueSnapshotReader(KVSR) does not exist.After this PR:
==COMMIT_MSG==
KVSR exists, and calls to
getandgetRowsgo through it.==COMMIT_MSG==
Priority: High P2
Concerns / possible downsides (what feedback would you like?):
getRowsAPI is weird. I do want to change it, but I think that should happen separately - I'd want us to reason through the allocation path and satisfy ourselves that we won't be causing (too many) additional allocations.SnapshotTransactionbecause the other endpoints like getRowsColumnRange need the post-filtering logic still. This will go away at the end of Phase III, but until then this duplication exists. It is navigable through code search and this code is not frequently changed, and I'm not sure we can split this out more easily.Is documentation needed?: No.
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?: No
Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?: No
The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.): Yes
Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?: I don't think so
Does this PR need a schema migration? No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?: That the SnapshotTransaction tests provide good enough coverage.
What was existing testing like? What have you done to improve it?: SnapshotTransaction is well tested.
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.: N/A
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?: N/A
Execution
How would I tell this PR works in production? (Metrics, logs, etc.): User calls still work
Has the safety of all log arguments been decided correctly?: I checked these, yes.
Will this change significantly affect our spending on metrics or logs?: No.
How would I tell that this PR does not work in production? (monitors, etc.): User calls don't work, service status/500s alerting.
If this PR does not work as expected, how do I fix that state? Would rollback be straightforward?: Rollback
If the above plan is more complex than “recall and rollback”, please tag the support PoC here (if it is the end of the week, tag both the current and next PoC):
Scale
Would this PR be expected to pose a risk at scale? Think of the shopping product at our largest stack.: No
Would this PR be expected to perform a large number of database calls, and/or expensive database calls (e.g., row range scans, concurrent CAS)?: No
Would this PR ever, with time and scale, become the wrong thing to do - and if so, how would we know that we need to do something differently?: Some of the duplication won't last.
Development Process
Where should we start reviewing?: KeyValueSnapshotReader
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?: It was hard to remove smaller components.
Please tag any other people who should be aware of this PR:
@jeremyk-91
@sverma30
@raiju