Fallbacks, automatic/general invalidation, Redis Optimizations, IScopedCache

[AwMalka]

RedisNotifier

• new policy option: GeneralInvalidationChannel to support invalidation requests by external orchestrator

InMemory

• new policy option: OnSyncProviderFailure to enable

1. Fallback expiry policy
2. Automatic Invalidation on connection state change

LayeredCache

• new policy option: InvalidateLevel1OnLevel2Update
  whenever Level2.Set is invoked (including Get(key, getter))
  automatically publish CacheItemActionTypes.Updated

RedisClient

• Reuse multiplex connections by name instead of creating new connections per cache manager
• Invalid AbsoluteExpiration handling bug fix

---

3 new cache types: that relies on the new CacheDirectives

• InMemoryScopedCache
• RedisScopedCache
• LayeredScopedCache

CacheableActionFilterAttribute (WebApiExtended/WebApiExtended.NETCore)
for automatically setting CacheDirectives on scope web api actions

Using the new CacheDirectives, the consumer is able to effect cache method used (None/Get/Set/GetOrSet) and to specify the acceptable response age based on its own specific BL (using MinimumValueTimestamp)

Use cases for example:
Service A provides CustomerDetails

Service B needs CustomerDetails.RegistrationDate which doesn't change over time so cache result is always accepted
Service C has a BL which can accept CustomerDetails retrieved in the last 30 minutes
Service D has a BL which can accept CustomerDetails retrieved at least after a specific timestamp
Service E BL requires up-to-date CustomerDetails (no-cache)

by using CacheableActionFilterAttribute and *ScopedCache defined with slidingExpiration of 30 minutes we can serve all listed above easily and safely using a single endpoint in Service A

as a bonus, it makes it easier to retrieve data from replicated datasources while taking into consideration replication lags by relying on ValueTimestamp/MinimumValueTimestamp and GetScoped/SetScoped added functionalities

[AwMalka]

Hi Danny,

I had a design review and partial code review by Roni and his team
and Zoar reviewed the unit tests

I've made some changes per your request, please check again and let me know what you think.

Thanks,
Avi

[amitla]

@AwMalka Adding to a public interface is effectively a breaking change (one interface changed for instance is ICacheNotifier). We need to reflect this in the version - it should be version 5.0.0

I'm still going through the changes, but in general - anywhere you have a change to a public interface (and/or class for that mater) - update major version (version, file version and assembly version).

If there are no changes to a public interface -> only update version and file version and leave assembly version as is