Issue Type: Patch Created: 2010-05-18T08:37:51.000+0000 Last Updated: 2010-07-30T09:32:54.000+0000 Status: Resolved Fix version(s): - 1.10.8 (25/Aug/10)
Reporter: Authenticus Nomen (cognomen) Assignee: Andy Fowler (andyfowler) Tags: - Zend_Cache
Related issues: Attachments: - Apc.php.patch
I'm trying to use TwoLevels cache backend in cache for DB metadata. I'm using default slow and fast backends (File and Apc). Here is a sample of code:
$cache = Zend_Cache::factory( 'Core', 'TwoLevels', array( 'automatic_serialization' => true, 'lifetime' => 86400 ), array( 'slow_backend_options' => array( 'cache_dir' => '/www/cludisc/tmp/tp_cache/dbmetadata' ) ), false, true ); $table = new TableClass(array( 'db' => $db, 'metadataCache' => $cache )); echo $table->find(123456)->current()->ID;
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:
127c127,132
$removableData = apc_fetch($id); if ($removableData) { return apc_delete($id); } else { return true; }
Posted by Authenticus Nomen (cognomen) on 2010-05-18T22:42:11.000+0000
Patch that fixes this issue
Posted by Andy Fowler (andyfowler) on 2010-07-30T07:37:58.000+0000
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).
Includes test.