By first running when metadata isn't cached I get a notice "Failed saving metadata to metadataCache". I think a cause of this notice may be in Zend_Cache_Backend_TwoLevels->save() method. When usage of fast backend is too high and data is saved by a slow backend only there is a try to remove this data from fast backend (line 203 in Zend/Cache/Backend/TwoLevels.php). When Apc backend is used as fast one apc_delete() function is called in this case (line 127 in Zend/Cache/Backend/Apc.php). But there could be cases in which this data isn't in fast backend. In this case apc_delete() returns FALSE and save() method of metadata cache returns FALSE too as a result (line 825 in Zend/Db/Table/Abstract.php). It causes generating a notice at the next line. As a solution of this problem the following patch for Zend/Cache/Backend/Apc.php may be used:

Comments

I'm trying to decide if the patch is the proper solution, or if TwoLevels should just ignore the result of _fastBackend->remove(). The patch adds some overhead to delete() (which is probably not much of a choke point.)

Posted by Andy Fowler (andyfowler) on 2010-07-30T09:32:47.000+0000

Fixed in r22736. Updated TwoLevels->save() to handle fast backends that return false for remove() operations that don't have existing keys (APC and File behave this way).