chore: update info regarding cache controller #941
Conversation
|
| | check-iterator-cache-enabled | Enables in-memory caching of database iterators. Each iterator is the result of a database query, for example, usersets related to a specific object, or objects related to a specific user, up to a certain number of tuples per iterator | | ||
| | check-iterator-cache-max-results | Configures the number of tuples that will be stored for each database iterator | | ||
| | check-iterator-cache-ttl | Specifies the time that items will be kept in the cache of database iterators | | ||
| | cache-controller-enabled | When enabled, cache controller will verify whether check subproblem cache and check iterator cache needs to be invalidated when there is a check or list objects API request. The invalidation determination is based on whether there are recent write or deletes for the store. This feature allows a larger check-query-cache-ttl and check-iterator-cache-ttl.| |
There was a problem hiding this comment.
The invalidation determination is based on whether there are recent write or deletes for the store.
Just if there is recent writes/deletes? Is it not also looking at if the recent writes/deletes are related to the check/LO request?
There was a problem hiding this comment.
This feature allows a larger check-query-cache-ttl and check-iterator-cache-ttl.
at the expense of...?
Thinking of it from a user perspective, it's not clear why this feature is not ON by default.
There was a problem hiding this comment.
is it not also looking at if the recent writes/deletes are related to the check/LO request
Partially - if there are many recent changes, it will invalidate all subproblem cache and iterator cache. If there are only a few recent changes, it will invalidate subproblem cache and only the iterator cache associated with the recent changes.
I am a bit hesitant to add this distinction here to avoid confusing the reader.
There was a problem hiding this comment.
at the expense of
at the expense of additional datastore queries for recent writes and deletes.
| | check-iterator-cache-max-results | Configures the number of tuples that will be stored for each database iterator | | ||
| | check-iterator-cache-ttl | Specifies the time that items will be kept in the cache of database iterators | | ||
| | cache-controller-enabled | When enabled, cache controller will verify whether check subproblem cache and check iterator cache needs to be invalidated when there is a check or list objects API request. The invalidation determination is based on whether there are recent write or deletes for the store. This feature allows a larger check-query-cache-ttl and check-iterator-cache-ttl.| | ||
| | cache-controller-ttl | Specifies the time that cache controller result is cached. While cache controller result is cached, server will not read datastore to check whether subproblem cache and iterator cache needs to be invalidated. | |
There was a problem hiding this comment.
While cache controller result is cached, server will not read datastore to check whether subproblem cache and iterator cache needs to be invalidated
This contradicts the cache-controller-enabled description: "When enabled, cache controller will verify whether check subproblem cache and check iterator cache needs to be invalidated when there is a check or list objects API request."
Is this intended? Can we clarify?
There was a problem hiding this comment.
If cache controller is enabled and cache controller result is cached, it will not query the datastore to verify whether invalidation is needed. If cache controller is enabled but result is not in cache, it will query the datastore to verify whether invalidation is needed.
Description
Updating how cache controller affects consistency. Should not be merged in until OpenFGA v1.8.5 is released.
References
Review Checklist
mainTesting