#23448 closed defect (bug) (fixed)
Passive invalidation via last_changed should use timestamps
Reported by: | westi | Owned by: | ryan |
---|---|---|---|
Milestone: | 3.6 | Priority: | high |
Severity: | major | Version: | 3.6 |
Component: | Cache API | Keywords: | has-patch |
Focuses: | Cc: |
Description
For #23173 we are switching lots of things over to passive invalidation via cache incrementors and last_changed.
This includes switching the oldest thing we had using this method of invalidation over to using wp_cache_incr
.
This ticket is a petition to use time()
still as the initial value so as to avoid race conditions with cache evictions and cache incrementors.
Currently with a 1 based last_changed key the following is possible with a persistent object cache backend like memcache:
- last_changed is set to 1
- list of pages is cached with 2 pages being the result of a get_pages call
- last_changed is evicted from the memcache server
- Another page is added
- A call to get_pages happens, sets last_changed to 1 and returns the old data
Confusion the reigns for a bit until other things are evicted or another change is made.
If we start with last_changed = time()
then we have no danger of using stale cache entries.
Attachments (1)
Change History (13)
#2
@
12 years ago
This patch should fix all these issue, it breaks all the tests that assume we start from 1 and increment up though ;)
#6
in reply to:
↑ 3
@
12 years ago
Replying to ryan:
How about microtime()?
That would work too, anything that doesn't always start somewhere deterministic is what matters :)
Switch to
time()
based last_changed