You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firstly, all client instances to the same Redis node (i.e. one connection pool) must share the cache, so it won't work to have a cache per connection in the underlying eredis process.
Instead eredis needs to forward the invalidations to the cluster client. I guess a callback-based solution in eredis would be best for this, e.g. a config {invalidate_cache_callback, fun()}.
If RESP3 is used, we can get off-band invalidations in the same connections as the (GET, SET, etc.) commands. Otherwise, a dedicated subscription process is needed.
For the caching, I see two possibilities:
Use an ETS table and handle invalidations by deleting from the table.
Use a callback interface, to let the application handle the caching. This would be similar to what we need to do for eredis.
For the tracking of keys, there are multiple variants and this needs to be investigated futher. (TODO: Update this issue with more info.)
The text was updated successfully, but these errors were encountered:
Redis supports client-side caching. How can we support it?
Firstly, all client instances to the same Redis node (i.e. one connection pool) must share the cache, so it won't work to have a cache per connection in the underlying eredis process.
Instead eredis needs to forward the invalidations to the cluster client. I guess a callback-based solution in eredis would be best for this, e.g. a config
{invalidate_cache_callback, fun()}
.If RESP3 is used, we can get off-band invalidations in the same connections as the (GET, SET, etc.) commands. Otherwise, a dedicated subscription process is needed.
For the caching, I see two possibilities:
For the tracking of keys, there are multiple variants and this needs to be investigated futher. (TODO: Update this issue with more info.)
The text was updated successfully, but these errors were encountered: