Zend Framework

Notice "Failed saving metadata to metadataCache" appears when TwoLevels cache backend is used for DB metadata caching

Details

  • Type: Patch Patch
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.10.4
  • Fix Version/s: 1.10.8
  • Component/s: Zend_Cache
  • Labels:
    None

Description

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
< return apc_delete($id);

> $removableData = apc_fetch($id);
> if ($removableData) { > return apc_delete($id); > } else { > return true; > }

Activity

Hide
Authenticus Nomen added a comment -

Patch that fixes this issue

Show
Authenticus Nomen added a comment - Patch that fixes this issue
Hide
Andy Fowler added a comment -

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.)

Show
Andy Fowler added a comment - 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.)
Hide
Andy Fowler added a comment -

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.

Show
Andy Fowler added a comment - 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.

People

Vote (1)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: