Implement a locking framework and make caching pluggable
Damien Tournoud - January 14, 2009 - 10:26
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
Jump to:
Description
This is a spin-off of #251792: Implement a locking framework for long operations for D7 only.
The issue is still the same: when a cache entry expire and need to be regenerated (think locale cache, menu cache, etc.), several regeneration can occur in parallel because we currently have no locking. This hurts badly websites that sustain high request rates, especially in cluster environments.
The D7 implementation will be very different from the D6 one:
- The system will comply to our new pluggable paradigms.
- We will strongly link caching and locking. This make sense because we are generally locking to prepare a cached object: if using an APC cache for example, that is local to each web node, we don't need to lock the whole cluster.
- We will have a new (probably fluent) API.
#1
Thanks Damien. Subscribing.
#2
Subscribe as well
#3
Perhaps we should wait for #363787: Plugins: Swappable subsystems for core?
#4
We should not postpone in favor of extremely early stage patches that are only slightly related. We have substantial issues here that need review beyond just the mechanics of how we make something pluggable. The only answer to that question in terms of this issue is"we make pluggable using the standard practice in core" which is not handlers right now.
Also, please do not change status with a msg like "perhaps".
#5
Subscribing.
#6
+1
#7
This issue seems to be idling a bit. what do we need to push this forward, and is it too late for D7 already?
#8
subscribe, I'd like to see and review how you implement the locking mechanism :)
#9
#251792: Implement a locking framework for long operations has a patch for D7 as RTBC, is this issue here still needed?
#10
Yep, let's close that.