Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address memory caching topic issues #6808

Closed
guardrex opened this issue Jun 2, 2018 · 0 comments
Closed

Address memory caching topic issues #6808

guardrex opened this issue Jun 2, 2018 · 0 comments
Labels
Milestone

Comments

@guardrex
Copy link
Collaborator

guardrex commented Jun 2, 2018

Cache in-memory in ASP.NET Core
https://docs.microsoft.com/aspnet/core/performance/caching/memory
performance/caching/memory.md

From @user135711 at #5495 (comment) ...

On the in memory Caching sample, please add an explanation of how cache dependencies work. I've been trying to figure it out from the source code and debugger, and the Docs don't provide sufficient explanation:

    using (var entry = _cache.CreateEntry(CacheKeys.Parent))
    {
        // expire this entry if the dependant entry expires.
        entry.Value = DateTime.Now;
        entry.RegisterPostEvictionCallback(DependentEvictionCallback, this);

        _cache.Set(CacheKeys.Child,
            DateTime.Now,
            new CancellationChangeToken(cts.Token));
    }

How does the child token above communicate to the parent token to evict and what is the purpose of disposing of the parent token? Is this a hack where the parent eviction only occurs because the already marked as expired parent gets evicted when the child cancellation triggers a remove expired entries search?

Second suggestion add to sample app a compatible version of this dependent cache entries construction because it makes more sense: aspnet/Caching#48

Additional

  • The sample app is MVC, not Razor Pages.
  • The topic is in need of a UE pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants