v0.10.0-preview1
Pre-releaseπ§ββοΈ Adaptive Caching (more)
FusionCache now supports adaptive caching!
This means having new GetOrSet
overloads where it is possible to change some options inside the factory, to be able to adapt (hence the name of the feature) some of these options to the object being cached. A typical example is caching a fresh news article for a small Duration
, and an old one for a higher one.
More examples and explanations in the related documentation.
π Better lock perf (in some scenarios)
There's a new optimization that kicks in automatically during a GetOrSet
call if:
- fail-safe is enabled (via
IsFailSafeEnabled
) - AND there's an expired entry available as a fallback
- AND a
FactorySoftTimeout
has been specified - AND
LockTimeout
has NOT been specified (pretty common)
In this case it may happen that a during multiple concurrent GetOrSet
calls for the same key, the first one acquired the lock and start executing the factory. During this time the other GetOrSet
calls for the same cache key are put on hold (to prevent a cache stampede, see here). But if the factory takes too much time it doesn't make sense to wait for it for the other callers, if they allow fail-safe and there's stale data to use as a fallback.
So with this optimization this is exactly what happens, maybe granting a perf boost in thee situations.
NOTE: these early-returning GetOrSet
calls btw will NOT temporarily re-save the stale data in the cache, because the currently running factory will do so nonetheless, and because doing so does not incur in extra factory calls, so we are still protected from the cache stampede problem.
π Added HasDistributedCache
A new bool
property has been added to IFusionCache
to let you know if there is a distributed cache configured (like the already existing HasBackplane
).
π Logging (new warning in a specific case)
Added a warning log when setting up a backplane in this scenario:
- a backplane is configured
- AND a distributed cache is NOT configured
- AND the option
DefaultEntryOptions.EnableBackplaneNotifications
is set totrue
This is important to prevent shooting yourself in the foot without knowing it, and that may happen because without a distributed cache there is no shared state between nodes, and if by default the backplane notifications are enabled it means that every time something is put into the cache in a node, all the other nodes will wipe their copy, creating a never ending update-remove-update-remove-etc loop.
You can read more about a scenario like this in the backplane documentation.
π Tell me what you think
Please try it out and let me know so I can push the final version out.