Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async read cache-aside, and a footstep towards async_this store decorator #62

Open
thorwhalen opened this issue Apr 30, 2020 · 0 comments

Comments

@thorwhalen
Copy link
Member

thorwhalen commented Apr 30, 2020

The read cache-aside pattern pops up often enough, but right now the implementation is sequential, which slows things down a bit. In the case where the data is not in the cache, once it's retrieved from its source, it would be nice for the process of caching not to block the user from starting to use the data immediately.

So instead of the current (see mk_memoizer in caching.py):

...
cache_store[k] = val  # cache it
return val

we'd like

...
async_this('cache_store[k] = val')  # cache it asynchronously
return val

Could be very easy, but need to think about what this could cause, and if the potential "harm" is important. For example:

  • Thinking we don't have the data in the cache because it's not finished writing, and therefore asking for the data from the source again: Not a big "harm".
  • Thinking we have data in the cache (because we see the file exists), but the data didn't finish writing, and therefore we get corrupt data... That could be harmful, and we'd like to avoid that. But how do we do so with any cache store that is given to us. Possible solution: A store wrapper that adds some safe async stuff on writes. So more like this solution:
...
async_cache_store = async_this(cache_store)  # wraps a store so it writes asyncly
...
cache_store[k] = val  # will write asynchronously
return val

cache-aside

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant