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
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.
The text was updated successfully, but these errors were encountered:
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 ownZiggyCreatures.Caching.Fusion.Locking
namespace.The standard implementation will be provided (
StandardMemoryLocker
) but for now it will be kept asinternal
since there's no need to expose the type directly.Also, the old
FusionCache
constructor with theIFusionCacheReactor
param will be marked as[Obsolete]
and a new one with anIFusionCacheMemoryLocker
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.The text was updated successfully, but these errors were encountered: