![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#23448 closed defect (bug) (fixed)
Passive invalidation via last_changed should use timestamps
| Reported by: | westi | Owned by: | ryan |
|---|---|---|---|
| Priority: | high | Milestone: | 3.6 |
| Component: | Cache API | Version: | 3.6 |
| Severity: | major | Keywords: | has-patch |
| Cc: | Focuses: |
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
@
13 years ago
This patch should fix all these issue, it breaks all the tests that assume we start from 1 and increment up though ;)
Switch to
time()based last_changed