How is the total expiration time calculated in NCache?

The total time an item takes to be removed from the cache is calculated as the sum of the expiration time, the Clean Interval, and the time taken by the cleanup activity.

How do Absolute and Sliding expiration differ?

Absolute expiration invalidates an item at a fixed date and time (stored in UTC), while Sliding expiration resets the expiration interval every time the item is accessed by the application.

How do expiration work in different NCache topologies?

In Mirror and Replicated topologies, a coordinator node handles expiration; in Partitioned and Partition-Replica topologies, each node is responsible for its own data expiration.

Data Expiration Types and Strategies: Overview

NCache provides several sophisticated time-based data invalidation strategies to ensure data integrity and optimize cluster storage by allowing you to specify exact times or intervals for data expiration. This is particularly effective when the frequency of data change is predictable. For instance, static region information is invalidated less frequently than rapidly changing product stock levels. By expiring stale data, NCache ensures that clients always receive the most relevant, fresh data from the database upon the next request.

Beyond data freshness, these strategies are essential for session management, allowing idle or inactive sessions to be automatically removed to free up resources. When an item is added to the cache, an expiration value is assigned, and NCache maintains a specialized index for these items.

Data removal is handled by a dedicated thread that checks for expired items based on a configurable Clean Interval (which is set to 15 seconds by default). The total latency for an item’s removal is calculated as:

$$\text{Total Time} = \text{Expiration Time} + \text{Clean Interval} + \text{Cleanup Activity Time}$$

Because of this formula, it is critical to calibrate the Clean Interval in accordance with your specific data expiration requirements to maintain a high-performance, fresh data set across various clustered topologies.

Absolute Expiration for Stale Data Prevention

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.

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 for Session Management

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.

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.

Configurable Default Expiration Strategies

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.

Cluster-wide Expiration Handling and Topologies

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.