Data Expiration Types and Strategies: Overview
NCache provides support for time-based data invalidation, allowing you to set a specific time or interval for cache data to expire. This method of invalidation is particularly useful in scenarios where the frequency of data changes can be determined. For instance, region data may not change frequently, making time-based expiration an ideal approach to invalidate such data.
Furthermore, expiring outdated data from the cache ensures that the client receives relevant and up-to-date information. For example, the 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 period will result in fresh data loaded into the cache on the next client request.
Another application of data expiration is session management. If a session remains inactive for a specified duration, it can be removed from the cache due to its idle state.
An expiration value is added to 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 elapses, 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 the expiration time specified by clients (in any time zone) will be converted to UTC on the cache server and the item will expire on the exact date and time as specified by clients. You can specify the expiration time ranging from seconds to days and months.
Note
This feature is also available in NCache Professional.
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 the item will be removed within the time frame of 15-25 seconds.
Sliding Expiration
In this 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. Every time the user accesses the cache data with Sliding Expiration, its cache life will extend by the specific expiration interval, e.g., an item with 30 seconds Sliding Expiration will be removed from the cache if the user will not access it for at least 30 seconds. However, with each access, the item's expiration interval will reset to 30 seconds, extending its life in the cache by 30 seconds.
Note
This feature is also available in NCache Professional.
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 expiration interval will be reset to 15 minutes in the cache.
Similar to Absolute Expiration, cache items with Sliding Expiration are removed on the cache Clean-up Interval.
Warning
If no expiration is provided with the cache item, it will reside in the cache till explicit removal. This can overwhelm the cache storage.
Also please refer to Eviction Policies which is another feature of NCache to control cache storage usage.
Default Expirations
NCache also supports default expirations that can aid you in setting your data invalidation strategies with more flexibility. Default expirations are configured via the NCache Management Center 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 the Product class is added to the 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 the NCache Management Center or config.ncconf, without any code change.
There are multiple scenarios where the configuration of expiration policy through the NCache Management Center 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 the Mirrored topology, the active node will perform expiration and synchronize it on the passive node.
- In the Replicated cache, expiration is performed by the coordinator node and the operation will then be synchronized to the other clustered nodes.
- In the Partitioned topology, as data is distributed on separate nodes, each node is responsible for its own item expiration.
- For Partition-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 synchronized with the cache, as it causes inconsistency if the value slides in the clustered cache but not in the client cache.
See Also
Absolute Data Expiration in Cache
Sliding Expiration
Eviction
