[ASP. NET] What if I set the cache "sliding expiration time" to 1 second?

Today, I wrote a component using ASP. NET Caching. I found an interesting problem when writing Unit Test for it. Next, I will explain this problem through a simple example. We wrote the following program in a console application, which is very simple: we get the Cache object that represents the current Cache through the static attribute Cache of HttpRuntime, and the Insert method is called to cache the current time. Note that we adopt the "sliding time" Expiration Policy and set this sliding time to 1 second. 1: class Program 2: {3: static void Main (string [] args) 4: {5: string key = Guid. newGuid (). toString (); 6: HttpRuntime. cache. insert (key, DateTime. now, null, Cache. noAbsoluteExpiration, new TimeSpan (0, 0, 1); 7: for (int I = 0; I <5; I ++) 8: {9: Console. writeLine (HttpRuntime. cache. get (key )?? "N/A"); 10: Thread. sleep (500); 11 :}12 :}13 :} next we extract the cache time in a for loop and display it on the console, each iteration has a sleep time of 0.5 seconds. According to the cache's sliding Time Expiration Policy, because we read the cache every 0.5 seconds, the cache will not expire during this period. The execution result shown below tells us that the added cache expires in 1 second. 1: 4/1/2014 2:51:12 PM 2: 4/1/2014 2:51:12 PM 3: N/A 4: N/A 5: N/A is the ASP. NET cache mechanism wrong? Actually not. The real reason is that we set the sliding expiration time range too small. To verify this, we set the time to 2 seconds as follows. 1: class Program 2: {3: static void Main (string [] args) 4: {5: string key = Guid. newGuid (). toString (); 6: HttpRuntime. cache. insert (key, DateTime. now, null, Cache. noAbsoluteExpiration, new TimeSpan (0, 0, 2); 7: for (int I = 0; I <5; I ++) 8: {9: Console. writeLine (HttpRuntime. cache. get (key )?? "N/A"); 10: Thread. sleep (500); 11 :}12 :}13 :} after running our program again, the output result is as follows. We can see that the added cache has not expired. 1: 4/1/2014 2:59:15 PM 2: 4/1/2014 2:59:15 PM 3: 4/1/2014 2:59:15 PM 4: 4/1/2014 2:59:15 PM 5: 4/1/2014 2:59:15 PM by checking the source code, we found the root cause of this problem: if we specify the slidingExpiration parameter when calling the Insert or Add method of Cache, the system will modify the expiration time (current time + slidingExpiration) of the Cache item for each extraction operation ). However, the modification of the expiration time is based on the premise that the time specified by the slidingExpiration parameter must be greater than the set minimum time, this time corresponds to the internal type CacheExpires with the static read-only attribute TimeSpan MIN_UPDATE_DELTA defined as follows. We can see that the time span is exactly one second. Therefore, if the specified slidingExpiration parameter is less than 1 second, it does not actually play the role of "sliding expiration. Of course, in real projects, we will not set the sliding time so short. 1: internal sealed class CacheExpires 2: {3: // other Member 4: internal static readonly TimeSpan MIN_UPDATE_DELTA = new TimeSpan (0, 0, 1); 5 :}