[wp-trac] [WordPress Trac] #15545: When using a persistent cache, there is a race condition in get_metadata()
WordPress Trac
wp-trac at lists.automattic.com
Tue Nov 23 00:35:59 UTC 2010
#15545: When using a persistent cache, there is a race condition in get_metadata()
--------------------------+-------------------------------------------------
Reporter: mdawaffe | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 3.1
Component: Cache | Version: 3.1
Severity: normal | Keywords: has-patch
--------------------------+-------------------------------------------------
{{{get_metadata()}}} does:
{{{
update_meta_cache($meta_type, $object_id);
$meta_cache = wp_cache_get($object_id, $meta_type . '_meta');
}}}
When using a persistent cache, another process could delete the cached
data between the first and second lines there, resulting in a value of
{{{false}}} for {{{$meta_cache}}}.
This can cause users to be cached without meta data (rare) or
{{{get_blogs_of_user()}}} to cache empty arrays (common).
Attached updates {{{update_meta_cache()}}} to always return valid (if
perhaps out of date) information for all requested IDs, not just the
previously uncached IDs.
Attached also uses this update to simplify {{{get_user_metavalues()}}}.
To prevent storing out of date information, {{{wp_cache_add()}}} should
probably be used with {{{update_meta_cache()}}} data (as opposed to
{{{wp_cache_set()}}}): users, *_meta, etc. I didn't audit everything (and
I'm not positive it's a concern), so this patch doesn't address the above
add v. set guideline. {{{get_blogs_of_user()}}} should probably do an add
instead of a set, though....
This patch is currently running on WordPress.com without problem... so far
:)
--
Ticket URL: <http://core.trac.wordpress.org/ticket/15545>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list