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

Common cache interface with atomic operations #68

Closed
AdamPflug opened this issue Dec 8, 2016 · 1 comment
Closed

Common cache interface with atomic operations #68

AdamPflug opened this issue Dec 8, 2016 · 1 comment

Comments

@AdamPflug
Copy link

Hey @BryanDonovan, great module.

I'm looking at this as potential solution to replace the caching layer on one of my projects (ExpressBrute) which currently has a bunch of its own caching storage adapters that are a pain to maintain and don't make sense to tie to my specific project. It seems like we both need a way to use multiple different caching stores with a unified interface

The only trick is, I need a way to do more than just get, set anddelete. Specifically I need access to an atomic way to do increment, so that multiple process can increment a counter without losing updates. For example without atomic increments, two processes can request the current count (e.g. 1), both processes increment that count by one and then both processes update the count to the new value (e.g the count becomes 2, instead of 3).

So I guess my question is: do you define a set API for your cache storage engines to target right now? And how are updates to that API managed? It seems like we need something like accord or waterline, but for cache stores. I don't know if you're already doing that or if it's something you're interested in doing.

Obviously increment can polyfilled in a non-atomic way with a get and a set and it will work across all stores until they they update to support the atomic method 1 by 1. If the underlying store doesn't support atomic increments (redis, mongo, and memcached all do), then the polyfill can just be left in place and it's not a big deal.

Thoughts on how to proceed?

@BryanDonovan
Copy link
Collaborator

Hi @AdamPflug.

Yeah, the difference among cache implementations is a bit of a pain. This is why I recommend that users write their own cache "adapter" between cache-manager and whatever store they're using, much like the example redis store (https://github.com/BryanDonovan/node-cache-manager/blob/master/examples/redis_example/redis_store.js). Then the user can add things like logging, etc. to that layer.

As for an API, I don't really define anything other than defining the methods here: https://github.com/BryanDonovan/node-cache-manager/blob/master/lib/caching.js#L133

It only requires get and set to be implemented. If another method, such as increment needs to be added, we can just add it there.

Do you have a particular cache store that has an increment method?

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

2 participants