From MSDN:
The main differences between the Cache and MemoryCache classes are
that the MemoryCache class has been changed to make it usable by .NET
Framework applications that are not ASP.NET applications. For example,
the MemoryCache class has no dependencies on the System.Web assembly.
Another difference is that you can create multiple instances of the
MemoryCache class for use in the same application and in the same
AppDomain instance.
Reading that and doing some investigation in reflected code it is obvious that MemoryCache
is just a simple class. You can use MemoryCache.Default
property to (re)use same instance or you can construct as many instances as you want (though recommended is as few as possible).
So basically the answer lies in your code.
If you use MemoryCache.Default
then your cache lives as long as your application pool lives. (Just to remind you that default application pool idle time-out is 20 minutes which is less than 1 hour.)
If you create it using new MemoryCache(string, NameValueCollection)
then the above mentioned considerations apply plus the context you create your instance in, that is if you create your instance inside controller (which I hope is not the case) then your cache lives for one request
It's a pity I can't find any references, but ... MemoryCache
does not guarantee to hold data according to a cache policy you specify. In particular if machine you're running your app on gets stressed on memory your cache might be discarded.
If you still have no luck figuring out what's the reason for early cache item invalidation you could take advantage of RemoveCallback
and investigate what is the reason of item invalidation.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…