Move getReadVersion method to FDBRecordContext from FDBDatabase #698
Assignees
Labels
enhancement
New feature or request
Comments
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Sep 6, 2019
…text from FDBDatabase The old method is deprecated, and it has been replaced with a few different methods on FDBRecordContext. This is accompanied by additional information that tracks what the read version was in Java memory.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Sep 6, 2019
…ad versions With FoundationDB#698 resolved so that read version tracking happens in `FDBRecordContext`, this was relatively easy. It just required making an explicit call to `FDBRecordContext::getReadVersion` from within the `OnlineIndexer`. I have verified that it shows up and has reasonable values in some of the logs from the `OnlineIndexer` tests.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Sep 6, 2019
…priority configurable This adds a `setWeakReadSemantics` and a `setPriority` method to the `OnlineIndexer.Builder` method. Adding a way to set the weak read semantics was simple, as it was already a method on runners. To thread the priority through, I added a priority field to transactions and to runners, and then the online indexer exposes that. The `OnlineIndexer.Builder` method then sets the priority to `BATCH` (by default). I was tempted to make the default weak read semantics one that set causal read risky to true. This would make sense for the online indexer, as it can actually tolerate stale reads (as everything is committed anyway), but it also benefits from seeing its own writes, which causal read risky actually guarantees. However, that is technically a behavior change, though it should be easy to add later if desired. This is on top of FoundationDB#698 because (a) they conflict otherwise and (b) there are a few methods in FoundationDB#698 that this can use. It could use the underlying FDB methods, but I would prefer it use the new one instead. The extra instrumentation is also useful for determining if setting weak read semantics on the index build actually did anything as I could look at the GRV instrumentation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment, the method to get a read version lives in
FDBDatabase(partially so that it can then use that to inform its read version tracking), but it probably makes more sense inFDBRecordContext. ThenFDBRecordContextcan callFDBDatabase's methods for tracking versions, which is already how commit version tracking is done. This also patches two possible misuses of the API that can happen: (1) if one callsFDBDatabase.getReadVersionwith anFDBRecordContextfrom a different database, one can end up updating the wrong database's notion of what the most recent version is; and (2) if one callsgetReadVersionwith anFDBRecordContextthat has been created with a cached version, one can end up accidentally updating the time value of the most recent time one has seen that version incorrectly.The text was updated successfully, but these errors were encountered: