If a lock is acquired with a long life-time, and the request then dies without clearing it (e.g. if the web server crashes), the lock isn't cleared automatically, and there is no way to do it using the API (lock_release() and lock_release_all() only releases locks acquired in the same request).
I suggest adding a new method, e.g. lock_force_release($name), that force-releases the semaphore. Of course one should not call this without having checked that the original owner of the semaphore has indeed died.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | lock_force_release-4.patch | 4.74 KB | c960657 |
| #2 | lock_force_release-3.patch | 3.25 KB | c960657 |
| #1 | lock_force_release-2.patch | 3.2 KB | c960657 |
Comments
Comment #1
c960657 commentedThis adds lock_force_release($name).
I thought of adding lock_force_release_all(), but I think it is dangerous, because e.g. in the event of a server crash it will also remove any locks acquired after the server came back up. If we are to provide something along those lines, I suggest adding a function that returns a list of all locks currently held (so that the admin can inspect them and choose which to force-release using lock_force_release($name)). As an extra bonus this function could also return various information about each lock (e.g. when the lock was acquired, the process id of the request in which the lock was acquired, the server IP address (in a cluster), etc.) so that the admin would have a better way of deciding which locks can safely be force-released. But I guess this discussion belongs in a separate issue.
Comment #2
c960657 commentedComment #3
pounardI'm not sure this is a good idea, the right thing to do is probably to let really small lifetime on most lock we use in core. For all non system essential use, we probably should write a more complete application-level locking API.
Comment #4
c960657 commentedIf the lifetime is too short, you risk that the semaphores expire before the are released. This may cause some serious concurrency issues – issues that semaphores were meant to prevent. Also note, that “really small but not too small” is very dependent on the specific site and its current load.
I'd rather improve the existing API than having to maintain two locking APIs. I think core could also benefit from an improved API.
Here is a reroll of the old patch.
Comment #20
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #21
smustgrave commentedSince there's been no follow up in 3+ months going to close out. If still a desired feature please re-open updating any missing information
Thanks!