Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
Platform Sprint 144
Description
The problem is as follows:
Assume a new page is added to first level and second level cache. Assume the EhCache Element of the first level cache has a TTL of 1 day. Then, some content change triggers the first level cache to flush. Then, the next request gets a hit from the second level cache. Then from the second level cache element we compute the new TTL for the first level cache which is:
newTTL = secondLevelElement.getTimeToLive() - timeLived;
The secondLevelElement.getTimeToLive() however should not be the approximate 1 day (minus the timeLived). Namely the response should be recreated once the TTL of the second level cache is reached!
To understand this, think about the following scenario (with the current bug still in it):
1) A container creates response page1 for request '/foo' and stores it with a TTL of 1 day in primary cache and second level cache (second level cache stores an EhCache element with TTL of 1 day but has it self a TTL of its elements of say 5 minutes)
2) A content change (which might impact page '/foo' flushes the first level page cache
3) A new request fir '/foo' arrives, fetching the response from the second level cache and storing it again with a TTL of '1 day minus some time'
Now, of after (3) no content changes happen for some time, it might be that the response from the second level cache is cached in primary cache way too long (certainly given the fact that it might be stale because for example the content has changed)
To avoid the above scenario, we need to put in the second level cache a cloned ehcache element on which we can modify the TTL without changing the TTL of the original ehcache element which goes in the primary page cache