-
Notifications
You must be signed in to change notification settings - Fork 216
Cannot set SlidingExpiration and AbsoluteExpirationRelativeToNow on RedisCache #194
Comments
Hmm, it should be checked right here:
|
Correct, it is checked there in GetExpirationInSeconds(), however, that is only used to initially set the TTL/expiry on the redis key. The way the sliding expiration works, is that each "Get" will use the GetAndRefresh() method to update the key TTL/expiry. This is done by getting the SlidingExpiration and AbsoluteExpiration out of the metadata and passing them into the refresh method (shown here):
But the problem, I think, is that when the meta data is stored, it only accounts for the AbsoluteExpiration property (and it ignores the AbsoluteExpirationRelativeToNow property). This can be seen here:
When the metadata is written with the key, it should calculate an absolute expiration time based on EITHER the AbsoluteExpiration OR the AbsoluteExpirationRelativeToNow property. |
Here is a simple repro:
|
Ah, you are correct. We'll get this fixed. |
Fixed in 68829e2 |
When using the RedisCache you can set both a SlidingExpiration and an AbsoluteExpiration. For example, you can set a sliding expiration of 5 seconds and an absolute expiration of 60 seconds. If the cached item is accessed every 5 seconds it will remain in cache up until 60 seconds from the original creation.
However, this only works if you are setting the DistributedCacheEntryOptions.AbsoluteExpiration property. If you set the DistrubutedCacheEntryOption.AbsoluteExpirationRelativeToNow then only the sliding expiration is respected/used.
The meta-data stored in Redis for each cache entry includes only the SlidingExpiration and the AbsoluteExpiration values, but ignores the AbsoluteExpirationRelativeToNow property.
The AbsoluteExpirationRelativeToNow property is very convenient (as the caller often doesn't want to have to worry about calculating the actual expiration time, just specifying how far into the future it should be). However, it seems that this property should really cause all the same behaviors as the AbsoluteEpiration property.
Thanks for listening!
The text was updated successfully, but these errors were encountered: