Distributed Locking for Redis (Atomic updates), and Possibility for 2nd-Layer-only caching for an entry #123
Unanswered
cezarlamann
asked this question in
Q&A
Replies: 1 comment
-
Hi @cezarlamann and thanks for using FusionCache! Sorry for the delay in answering, I've been quite busy lately: I'll read this issue carefully and will let you know as soon as possible. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello everyone at ZiggyCreatures, how have you been?
First of all, thank you for this well made Caching API you guys made.
So, this is something that probably would pile-up on #59 #60 #66 and #90.
What I'm trying to accomplish here is something like this:
N instances of an application would try to access an external API that is OIDC-protected (OpenOAuth/OpenID Connect), so, before calling the methods of that external API, one of the instances would need to perform an authentication, which will return an object containing:
All the instances would use the token until it gets close to the expiration, and then the first that hits an expired token, should call the Auth API for a refreshed token (which usually not only returns a new Access token but also a new Refresh token).
There are APIs that perceive if a token has been compromised (e.g. calling twice the same API with the same refresh token - would render all tokens invalid till you re-authenticate).
The first client who would hit an expired entry (Redis), would set a lock there (e.g. RedLock - with RedLock.NET library), and perform an atomic update - Avoiding a stampede on the distributed level.
So, given this use-case, I believe it would be great for a "Distributed Cache-only for a specific entry" scenario, since a single value (access token) would be shared between application instances, and not an object that would be shared within each instance.
Furthermore, I think it would be a good fit for the Adaptive Cache feature. However, I don't know if the Backplane feature or anything else in the library would take care of the Atomicity in this regard.
I read somewhere in the docs, that you suggested the usage of Jittering for concurrent attempts on calling the "producer" function. But what should we do when the jitter is close enough (or even equal) that the "producer" function would be called more than once between clients?
If the library covers this kind of use case, could you guys please guide me on what should I do in order to accomplish this scenario?
On a (very) naive attempt on doing Atomic Redis caching based on IDistributedCache with RedLock.NET, I came to a solution like this:
Thank you in advance.
Beta Was this translation helpful? Give feedback.
All reactions