Allow for setting the store state cacheability during checkVersion #2203
Assignees
Labels
enhancement
New feature or request
Comments
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Jun 29, 2023
…ility during checkVersion A new record store configuration parameter is added. It can be configured to instruct `checkVersion` to update the `cacheability` flag. If the store header is alreadyin the desired state, then no update is performed. In addition, this allows the user to skip updating the flag if the store is pre-existing, which was the old behavior, and which is still important during roll outs. In particular, if the same set of instances are configured to operate on the same store, and some of them are configured to set cacheability to `true` while others to set it to `false`, then operations from the one set will always step on operations from the other set. To avoid that, one can first set the parameter to ignore existing stores and then make a second change to start updating existing stores again. This resolve FoundationDB#2203.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Jun 30, 2023
…ility during checkVersion A new record store configuration parameter is added. It can be configured to instruct `checkVersion` to update the `cacheability` flag. If the store header is alreadyin the desired state, then no update is performed. In addition, this allows the user to skip updating the flag if the store is pre-existing, which was the old behavior, and which is still important during roll outs. In particular, if the same set of instances are configured to operate on the same store, and some of them are configured to set cacheability to `true` while others to set it to `false`, then operations from the one set will always step on operations from the other set. To avoid that, one can first set the parameter to ignore existing stores and then make a second change to start updating existing stores again. This resolve FoundationDB#2203.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Jul 6, 2023
…ility during checkVersion A new record store configuration parameter is added. It can be configured to instruct `checkVersion` to update the `cacheability` flag. If the store header is alreadyin the desired state, then no update is performed. In addition, this allows the user to skip updating the flag if the store is pre-existing, which was the old behavior, and which is still important during roll outs. In particular, if the same set of instances are configured to operate on the same store, and some of them are configured to set cacheability to `true` while others to set it to `false`, then operations from the one set will always step on operations from the other set. To avoid that, one can first set the parameter to ignore existing stores and then make a second change to start updating existing stores again. This resolve FoundationDB#2203.
MMcM
pushed a commit
that referenced
this issue
Jul 12, 2023
… checkVersion (#2204) A new record store configuration parameter is added. It can be configured to instruct `checkVersion` to update the `cacheability` flag. If the store header is alreadyin the desired state, then no update is performed. In addition, this allows the user to skip updating the flag if the store is pre-existing, which was the old behavior, and which is still important during roll outs. In particular, if the same set of instances are configured to operate on the same store, and some of them are configured to set cacheability to `true` while others to set it to `false`, then operations from the one set will always step on operations from the other set. To avoid that, one can first set the parameter to ignore existing stores and then make a second change to start updating existing stores again. This resolve #2203.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The store state cacheability flag currently must be set by calling
setStoreStateCacheabilityon an openFDBRecordStore. This flips the flag in the store header, which then causes future updates to the store header to trigger updates the meta-data version key. This is a little awkward, in that it means that if a user wants to use the store state cache, they need to somehow separately orchestrate opening/creating the store and then enabling the store state cache.It seems like we should be able to control this during
checkVersion. We're already loading and writing the store state, so batching up this update with other things that happen duringcheckVersionwould seem to make sense. One thing that needs to be handled a little delicately is that if you had two instances trying to open the same store, and one of them was configured to always set the store state cacheability totruewhile the other was configured to set the store state cacheability tofalse, then they'd step on each other's toes while trying to interact with the store. So there needs to be a setting wherecheckVersionignores the current value of existing stores to avoid introducing too many conflicts.The text was updated successfully, but these errors were encountered: