[wp-trac] Re: [WordPress Trac] #5389: Suspend and resume object cache

[WordPress Trac]

#5389: Suspend and resume object cache
---------------------+------------------------------------------------------
 Reporter:  ryan     |        Owner:  anonymous
     Type:  defect   |       Status:  new      
 Priority:  normal   |    Milestone:  2.4      
Component:  General  |      Version:  2.4      
 Severity:  normal   |   Resolution:           
 Keywords:  cache    |  
---------------------+------------------------------------------------------
Old description:

> We sometimes need to suspend object cache operations, notably during
> installation and importing.  During install we want to know we are
> working with the raw DB values.  During import we want to avoid set/get
> trips to the cache (especially when using the memcached backend) for a
> potentially huge number of new objects -- objects that probably won't be
> requested again.  We also want to avoid the overhead of caching imported
> objects in memory.  With big imports we can bust the php memory limit.
>
> In some places, we check if WP_IMPORTING or WP_INSTALLING is set and
> disable cache sets and gets.  Not all cache backends do this however.
> Instead of references global defines, let's formalized this with two
> function calls, wp_suspend_cache() and wp_resume_cache().  When the cache
> is suspended, all cache gets return false and all sets/adds return true
> without actually setting anything.  Deletes should probably still be
> processed.  It is up to the caller to make sure it doesn't do things that
> would make the cache inconsistent with the DB while the cache is
> suspended.  Given our current model where we usually delete on change and
> add on read, this shouldn't be a problem.

New description:

 We sometimes need to suspend object cache operations, notably during
 installation and importing.  During install we want to know we are working
 with the raw DB values.  During import we want to avoid set/get trips to
 the cache (especially when using the memcached backend) for a potentially
 huge number of new objects -- objects that probably won't be requested
 again.  We also want to avoid the overhead of caching imported objects in
 memory.  With big imports we can bust the php memory limit.

 In some places, we check if WP_IMPORTING or WP_INSTALLING is set and
 disable cache sets and gets.  Not all cache backends do this however.
 Instead of referencing global defines, let's formalize this with two
 function calls, wp_suspend_cache() and wp_resume_cache().  When the cache
 is suspended, all cache gets return false and all sets/adds return true
 without actually setting anything.  Deletes should probably still be
 processed.  It is up to the caller to make sure it doesn't do things that
 would make the cache inconsistent with the DB while the cache is
 suspended.  Given our current model where we usually delete on change and
 add on read, this shouldn't be a problem.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/5389#comment:2>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software