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.

Comments

kbahey’s picture

Thanks Damien. Subscribing.

moshe weitzman’s picture

Subscribe as well

birdmanx35’s picture

Status: Active » Postponed
moshe weitzman’s picture

Status: Postponed » Active

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

Jeremy’s picture

Subscribing.

michtoen’s picture

+1

slantview’s picture

This issue seems to be idling a bit. what do we need to push this forward, and is it too late for D7 already?

CorniI’s picture

subscribe, I'd like to see and review how you implement the locking mechanism :)

coltrane’s picture

#251792: Implement a locking framework for long operations has a patch for D7 as RTBC, is this issue here still needed?

Damien Tournoud’s picture

Status: Active » Closed (duplicate)

Yep, let's close that.