[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