Proposal - Pluggable cache abstraction#142
Conversation
Hawxy
force-pushed
the
cachev2
branch
2 times, most recently
from
f2fed3c to
c221cd0
Compare
|
|
||
| [Test] | ||
| public void BackgroundCleanup_RemovesExpiredItems() | ||
| public async Task BackgroundCleanup_RemovesExpiredItems() |
There was a problem hiding this comment.
i don't think this test is valid anymore, i think it's passing because we can't determine if the background task removed the item or Get's lazy eviction did.
There was a problem hiding this comment.
If that's the case it was always broken, right? Get previously had the lazy logic.
| } | ||
|
|
||
|
|
||
| _cacheProvider = new DatastreamCacheDecorator(cacheProvider, _cacheTtl); |
There was a problem hiding this comment.
one thing to note in the case of local cache, we're going from each type having its own cache of 1000 entities to all of them sharing 1 cache of 1000 entities. maybe we should increase the default cache size or increase the local cache size if there is not user provided configuration value and datastream is enabled.
There was a problem hiding this comment.
That's true, but I'll leave it to your discretion as you know these entities better than I do.
2 participants
Hiya,
I'm looking at building some more advanced abstractions around this package in order to automate feature tracking & checking in ASP.NET Core, but at the moment this package doesn't integrate well with the wider ecosystem.
Like many modern .NET projects, we already have a L1 + L2 + Backplane caching solution via FusionCache, and I'd prefer to reuse all of that infrastructure to keep our nodes in sync as it's far less chatty than a pure redis cache. At the moment there isn't an easy to way to swap out the caching implementation globally, and so that's what I've proposed here.
The main change is the cache abstraction is provided as a non-generic interface and reused where required, rather than having a cache per-type which doesn't scale well.
The existing
RedisCachealso had a few issues that've been fixed as part of this:ConnectionMultiplexeris designed to be created once for the life of an application and reused where needed, not created per-cache. Projects that are already using Redis will have a pre-configured Multiplexer and libraries typically let users provide one rather than dealing with the Redis connection themselves, so most of the connection options have been made obsolete.Edit: I did another pass at the configuration options and aligned them with Microsoft's own Redis options for flexibility & familiarity.