Httpruntime.cache Study again

Extract:

As you can see: the read cache is actually called the Get method, while the write cache is the simplest version of the overload that calls the Insert method.

Note: The Add method can also put an object into the cache, this method has 7 parameters, and the insert has a similar overloaded version of the signature, which has a similar function: add the specified item to the System.Web.Caching.Cache object, which has dependencies, Expiration and priority policies, and a delegate that can be used to notify the application when an insert item is removed from the Cache. However, they have a small difference: when the cache entry to be added is already present in the cache, insert overwrites the original cache entry, and add does not modify the original cache entries.

In other words: If you want a cache item to be cached and not be modified, then calling add does prevent subsequent modifications. When the Insert method is called, the existing item is always overwritten (even if it was previously called add).

From another point of view, the effect of add is more like the behavior of static readonly, while the effect of insert is like static behavior.
Note: I'm just saying "like", in fact they have more flexible usage than normal static members.

Because cache entries can be accessed at any time, it does seem to be a bit of a static member's taste, but they have more advanced features such as cache expiration (absolute expiration, sliding expiration), cache dependencies (dependent files, dependency on other cache entries), removal of priorities, notification of cache removal, and so on. I will describe these four categories of features in the following sections.

In a multi-threaded environment, sharing a container, conflicts are unavoidable. If you simply want to cache some data and do not need many of the advanced features of the cache, consider not using the cache. For example: You can create a static instance of dictionary or Hashtable, it can also do some basic caching, but I want to remind you that you want to handle the data synchronization problem of multi-threaded access data yourself.
Incidentally: hashtable.synchronized (New Hashtable ()) is also a thread-safe collection, and if you want to be simple, consider it.

Asp. NET supports expiration policies for two types of cache entries: absolute expiration and sliding expiration.
1. Absolute expiration, this is easy to understand: it is when the cache is placed in the caches, specify a specific time. When the time reaches the specified time, the cached item is automatically removed from the cache.
2. Sliding expiration: Some cache entries, we may only want to keep in the cache when a user is accessing it, and only remove it if the user no longer accesses the cache entry for a period of time, which optimizes memory usage because it guarantees that the cached content is "hot". Is the memory of the operating system and the disk cache not all designed like this? And this very useful feature, the cache is also ready for us, as long as the cache entry in the cache, specify a sliding expiration time can be achieved.

The above two options correspond to add, the DateTime absoluteexpiration in the Insert method, and the TimeSpan slidingexpiration two parameters.
Note: These two parameters are used in pairs, but they cannot be specified as a "valid" value at the same time, only one parameter value is valid. When you do not use another parameter item, define two static readonly field assignments with the cache class.

These two parameters are relatively simple, I will not say more, just say: If you use the Noxxxxx two options, then the cache entries are kept in the cache. (may also be removed)

The ASP. NET cache has a powerful feature, which is caching dependencies. One cache entry can depend on another cache entry.

Not in the cache, the  string path = HttpContext.Current.Server.MapPath ("~/app_data/runoptions.xml") is loaded from the file;
2. Cache-dependent objects can also be SQL SERVER, refer to SqlCacheDependency

Httpruntime.cache Study again