Skip to content

v0.10.0-preview1

Pre-release
Pre-release
Compare
Choose a tag to compare
@jodydonetti jodydonetti released this 23 Apr 16:07

πŸ§™β€β™‚οΈ 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 to true

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.