An interesting patch landed on http://groups.drupal.org/node/59318 I wish to discuss stamped protection for the core cache further.

CommentFileSizeAuthor
#1 drupal-cache.inc-762978-D6.patch3.81 KBmikeytown2

Comments

mikeytown2’s picture

StatusFileSize
new3.81 KB

Here is a re-roll of rbuccigrossi's patch for 6.16 and I renamed his function and did some minor code cleanup & documentation. There is also patch from tag1
http://tag1consulting.com/patches/pagecache_lock

Both could potentially use the locking framework and both will suffer from missing js & css files due to aggregation. It would require this patch to land first most likely #721400: Order JS files according to weight, don't change filenames for aggregated JS/CSS & *might* require these functions to be redone
http://api.drupal.org/api/function/drupal_clear_css_cache/6
http://api.drupal.org/api/function/drupal_clear_js_cache/6

FiReaNGeL’s picture

From the blog post :

"In cache_get(), when we are asked to retrieve a page that has a cache entry that expired, we temporarily set the created time to 10 seconds in the future, but return 0 for the current request so that it updates the cache. This allows other requests to get the old cache copy while the current request updates the cache to the latest version. "

Would there be a way to serve the cache for the first request too? Mark as expired, generate it, but serve the cached version so that no user (not even the first one) has to wait?

Also, would it make more sense to port this first to D7 then backport it to D6?

Great feature to have in any way!

catch’s picture

Version: 6.x-dev » 7.x-dev
catch’s picture

Status: Active » Needs work

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.