Occasionally, about 1 out of 5 times, a node's cache isn't cleared when it is updated. Even going to view the revision that the update created or editing the node doesn't show the changes. Minimum cache lifetime is set to 1 minute but even after waiting for a minute and running cron it isn't automatically cleared.

It seems that this problem happens more during the site's busier times and we haven't been able to reproduce the issue in our development environment (which typically only has 1 user on it at a time). The cache tables are all InnoDB so I'm told this means we shouldn't need to worry about locking.

A similar problem with the chosen answer saying that this is just an issue of properly setting the minimum cache lifetime. But, I found this Drupal bug that implies that on node updates the cache should be cleared regardless of that setting. Though, its status is still "needs work" which maybe means a solution was never implemented and this is still the case.


Building off a patch in the bug and using hook_node_update I tried the following

function MYMODULE_node_update($node)
   // Forcibly wipe this node's page view from the cache because, if a
   // minimum cache lifetime is in effect, cache_clear_all() will not
   // clear any page cache entries younger than that minimum.
   // Page cache cids are absolute URLs.  url() in absolute-mode will
   // get the aliased path if there is one, and we also wipe the
   // absolute version of the node/nid URL just in case.
   // Copied from http://drupal.org/node/256416#comment-838118
   global $base_url;
   cache_clear_all( url('node/'.$node->nid, array('absolute' => true))
                  , 'cache_page' );
   cache_clear_all($base_url .'/node/'. $node->nid, 'cache_page');

This should work around the minimum cache limit and only clear the cache for that node. Unfortunately, this did not work.

Update 2

After digging further I discovered that running cache_clear_all('field:node:<nid>', 'cache_field') (where <nid> is replaced with the relevant node ID) cleared the correct cache when the problem cropped up. I tried putting this in a MYMODULE_node_update() hook but it did not resolve the issue.

In discovering this and following the path of the code I also discovered that the APC module is taking care of the caching and none of this is being stored in the database as I originally thought.

Knowing that the caching is being handled by APC and considering the intermittent nature of the issue it brings me back to a possible locking issue with APC. Would that even make sense? Preliminary searches have not revealed anything.

  • Are you using any custom cache modules such as Entity cache? Commented Aug 27, 2012 at 23:06
  • @JohnathanElmore The following: Alternative PHP Cache, Block Cache Alter, Memcache Admin.
    – donut
    Commented Aug 27, 2012 at 23:20

2 Answers 2


I updated the APC module to 7.X-1.0-beta4 from beta3 and it seems to have fixed the problem. At least the client has not reported any further issues for several days now and we have not been able to reproduce the issue in our somewhat limited testing.

I noticed nothing in the change lot between beta3 and beta4 that would suggest a fix to this issue. I'm not convinced that this is what fixed it, but I have no other clues.


Ended up having more issues after upgrading the APC module. Talked to some others offline about their experience with Drupal and APC and confirmed that others experienced locking issues with APC. Switched to using memcached and the Memcache module and all our problems were solved. Haven't had an issue since switching, over a year ago.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.