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

[FEATURE] 🔒 Extensible Memory Locking #192

Closed
jodydonetti opened this issue Feb 3, 2024 · 1 comment
Closed

[FEATURE] 🔒 Extensible Memory Locking #192

jodydonetti opened this issue Feb 3, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@jodydonetti
Copy link
Collaborator

jodydonetti commented Feb 3, 2024

Problem

FusionCache automatically protects us from Cache Stampede, which is very helpful.

To do that it internally uses a memory locking mechanism, which historically has been private: this currently limits the development of new 3rd party locking mechanisms by the community.

Solution

It is time to expose the internal abstractions and do so in a proper way, so that the community may be able to create their own implementations with different designs.

The old name of the interface was IFusionCacheReactor (kinda related to the whole "fusion" concept).
To do this well it would be better to change the name into something more "clean" and immediately understandable, so the new name of the interface is IFusionCacheMemoryLocker, sitting inside its own ZiggyCreatures.Caching.Fusion.Locking namespace.

The standard implementation will be provided (StandardMemoryLocker) but for now it will be kept as internal since there's no need to expose the type directly.

Also, the old FusionCache constructor with the IFusionCacheReactor param will be marked as [Obsolete] and a new one with an IFusionCacheMemoryLocker param will be created.
By doing so there's a very small potential issue with the compiler not being able to do overload resolution between the 2 constructors with the same number of params, but only in the rare case of somebody already using the old one by explicitly passing an inline and untyped null as the reactor, which I think is rare, if realistic at all.

The builder will be augmented to allow different memory lockers to be used, of course with the usual methods available like:

  • WithRegisteredMemoryLocker()
  • TryWithRegisteredMemoryLocker()
  • WithMemoryLocker(locker)
  • WithMemoryLocker(lockerFactory)

This should allow users to feel at home with the other components already configurable via the builder interface.

On top of the methods above there will be an additional method WithStandardMemoryLocker() that will explicitly tell the builder to use the standard one: it will not be necessary to call it, since by default the standard one is used, but still it's nice to have it for completeness.

@jodydonetti jodydonetti added the enhancement New feature or request label Feb 3, 2024
@jodydonetti jodydonetti added this to the v0.25.0 milestone Feb 3, 2024
@jodydonetti jodydonetti self-assigned this Feb 3, 2024
@jodydonetti
Copy link
Collaborator Author

Hi all, I just release v0.25.0 🥳

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

No branches or pull requests

1 participant