Data expiration contains elements that makes the cache allocation more efficient. The feature removes items that are not current from the cache, freeing the memory and the resources associated. The capabilities list looks like this:
Absolute time expiration
If the cache item has a property to include a specific date and time where the item will expire this will be removed automatically from the cache once the time has arrived. The cache will probably have a secondary monitor that scans each entry and in certain occasions, if the cache is advanced enough will just check the timespan dictionary.
This feature is quite important, when the client stores an item on the cache it will probably know for how long the object is current. Having some kind of expiration will allow architects and developers to keep a healthy cache. If this feature is not present the system can run easily into resource starvation, as the cache will grow without control.
Idle time expiration
When a cache has this capability the cache item will be removed from the cache if the item hasn’t been accessed in a period of time (usually configurable). This model implements a frequently access cache architecture.
This feature is useful when you have a very dynamic cache, for example when you want to store only the most accessed objects. The cache will only keep alive objects that are really shared and frequently used. In certain scenarios this type of behavior is tracked as it can give the developer information about access patterns.
Cache item evictions
Cache evictions occur when the cache removes item arbitrarily, this can happen when the cache is under memory pressure or other conditions that affect the storage stability. A cache with this feature will usually provide the developers the possibility of configuring the eviction rules.
If the cache does not have expiration at least it should have evictions. If neither feature is present is probably a bad cache choice therefore pay special attention to the combination of these features. A growing cache will hit a resource limit sooner or later, with 64bits the memory barrier has been moved quite far but you may still have certain exponential search time (annexed tables, relationships or any other index that cannot be hashed) that will consume CPU. Some kind of eviction is usually recommended.
If the cache implements priority eviction rules it will allow developers to assign a priority (usually a range) to an item, this will protect the item from arbitrary evictions when the cache is under pressure. Note that a priority eviction will not prevent the cache to remove the item if necessary, it will just follow an order.
If the cache has an eviction model and the data that the system needs to store is critical then an eviction rule like priority can help the designers to have some kind of protection against random evictions. Consider this feature if the system really has different cache items priority mode.
This is an advanced mode of eviction that combines the standard eviction with idle time expiration. The eviction can be configured using the least recently used (LRU) or least frequently used (LFU) in order to prevent useful cache items from being evicted from the cache.
This is a more sophisticated eviction model and should be used if eviction is needed as it will keep hot cache items loaded when under pressure. Note that this logic will usually incur into performance penalties as the cache needs to track the history of the cache item.
This feature is similar to the priority eviction but with an extra feature, marking cache items as “protected”. This means that the cache will not remove under any circumstance the stored item, even if is under pressure.
Eviction protection surplus the priority eviction, this feature is even better for critical data storage. The cache can guarantee that the item will not be evicted.
The average weight of this category is 2.67