Data Expiration Strategies Overview
NCache supports time-based data invalidation where you can specify the time or interval to expire your cache data. Time based data invalidation is used if changes to the data occur in a deterministic time fashion or where you can determine the frequency of data change. For example, region information may not be frequently updated, so you can use a time based expiration to invalidate such data.
Moreover, expiring stale data from the cache results in relevant and updated data being provided to the client. For example, units available for a certain product may be changed in the database, but not updated in the cache. Hence, expiring such data from the cache after a certain time period will result in fresh data being loaded into the cache on the next client request.
Another use of data expiration is in maintaining sessions. If a session has been inactive for a certain period of time, it can be removed from the cache as it is idle.
Clean Interval
Expiration value is added with the cache items. NCache maintains an index for items with time based expiration. A dedicated thread checks cache data for these expired items periodically after a configurable
interval of time called Clean Interval. By default, its value is 15 seconds, which means that the maximum time an item can take to be removed from the cache is (expiration time + clean interval + time taken by cleanup activity). Hence, you should select this interval carefully according to the expiration time of your data.
Absolute Expiration
You can add an item to the cache with absolute expiration by specifying the exact date and time at which the item should be invalidated. When this time is elapsed, the item will be removed from the cache. Here, NCache maintains UTC time for absolute expiration on the caching servers which facilitates the case where clients and cache servers are in different time zones. This means that expiration time specified by clients (in any time zone) will be converted to UTC on the cache server and the item will be expired on the exact date and time as specified by clients. You can specify the expiration time ranging from seconds to days and months.
However, note that the item will be removed when expired on the next cache clean up interval. For example, if you specify an expiration of 10 seconds with an item and cache clean up interval is configured to 15 seconds, then item will be removed within the time frame of 15-25 seconds.
Sliding Expiration
In Sliding expiration, you want the cache to retain the data as long as it is being used by the application and remove any data that has not been used for a specific period of time. Whenever cache data with sliding expiration is accessed, its time to live in cache is extended by the expiration interval specified, e.g. an item with 30 seconds sliding expiration will be removed from the cache if not accessed for at least 30 seconds. However, with each access, the item's expiration interval will be reset to 30 seconds, extending its life in the cache by 30 seconds.
For example, session data can be stored in the cache as long as the session is active. For this type of data, you can specify sliding expiration, let's say 15 minutes. Hence, if activity occurs within the specified time interval, the session's life will be extended by another 15 minutes in the cache.
Similar to absolute expiration, cache items with sliding expiration are removed on cache cleanup interval.
Warning
If no expiration is provided with cache item, it will reside in the cache till explicit removal. This can lead to cache storage overwhelming. Also please refer to Eviction Policies which is another feature of NCache to control cache storage usage.
Default Expirations
NCache has introduced a new set of default expirations that can aid you in setting your data invalidation strategies with more flexibility. Default expirations are configured via NCache Manager or config.ncconf, so there is no need to change the code if you want to change the expiration value which is passed via API. Moreover, if the same application requires multiple expiration values, default expirations can be used.
NCache provides the following default expirations:
- Default Absolute
- Default Sliding
- Default Absolute Longer
- Default Sliding Longer
All of the default expirations have a minimum value of 5 seconds.
Let's suppose Default Absolute is configured with 5 seconds and Default Sliding Longer expiration is configured with 10 seconds. An object of Product class is added to cache with Default Absolute and a session is added with Default Sliding Longer expiration. Once the object is added, you want to change the expiration value for both to 15 seconds. Instead of reinserting the objects with the new expiration values, you can simply change the configuration from NCache Manager or config.ncconf, without any code change.
There are multiple scenarios where configuration of expiration policy through NCache Manager and API will overlap, and will trigger the following behaviors. Note that non-default expiration refers to Absolute and Sliding expiration.
| Default Expiration | Expiration in API Call | Behavior |
|---|---|---|
| Configured | Default expiration | Default expiration |
| Configured | Non-default expiration | Non-default expiration |
| Configured* | None* | Default expiration* |
| Not Configured | Default expiration | No expiration |
| Not Configured | Non-default expiration | Non-default expiration |
| Not Configured | None | No expiration |
Important
*For CacheItem, the default value of Absolute and Sliding Expiration is NoAbsoluteExpiration and NoSlidingExpiration. Hence, if Default expiration is configured but no expiration is configured in API with CacheItem, NO expiration will take place as its default expiration value overwrites the configured Default expiration.
Expiration in Clustered Environment
In a clustered cache environment where multiple caching servers are involved, expiration is handled differently in various NCache topologies.
- In mirror topology, active node will perform expiration and synchronize it on passive node.
- In replicated cache, expiration is performed by coordinator node and the operation will then be synchronized to other clustered nodes.
- In partitioned topology, as data is distributed on separate nodes, each node is responsible for its own item expiration.
- For partitioned-replica topology, expiration will be performed on active nodes and propagate to their respective replicas.
- Client cache will utilize the same expiration enabled on the clustered cache. However, the Sliding expiration is added as Absolute expiration once it is synced with the cache, as it causes inconsistency if the value slides in the clustered cache but not in the client cache.