On 27 January 2010 17:20, listread <listr...@cze.com> wrote:
> I think I need to learn about semaphores! Any suggestions for a good
> One of the things we want to do is exclude locked records from a query.
> Will semaphores provide for that?
> - Ron
> On 1/27/2010 8:14 AM, Richard Quadling wrote:
>> The technique I've used in the past is semaphore locking, where the
>> semaphore contains the session and the expected expiry time.
>> Follow this.
>> User a starts the process of editing a record.
>> Set the semaphore where there is :
>> a - no existing semaphore - no ongoing edits.
>> b - the semaphore's session is the same - repeat edits by this user
>> in the same session (expired or otherwise).
>> c - the semaphore has expired - the other user simply took too long.
>> If the semaphore cannot be set it will be because of :
>> d - Different non expired session - someone else is editing the record.
>> When a user saves the row, you just remove the semaphore.
>> The semaphores could be in a separate table (rather than on the record
>> Different tables have different number of columns so take different
>> amounts of time to edit, so each table would have a different amount
>> of time from edit to expiry.
>> An entry on a lookup table (just a description) should, in the main,
>> be completed within 30 seconds.
>> But a detail line for a purchase order may take several minutes.
>> You'll have to tune this to your own needs.
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
A "semaphore" is just a flag. Nothing else. You can implement it in
any way you like as long as _ALL_ code related to locking uses the
A common technique for "locking" files is to create a folder called filename.lck
A directory can only exist or not.
You try to create the directory. If you did, you got the lock. If not,
someone else has.
The same approach should be used for DB locking in this manner.
You try to place the lock (with the conditions defined in the WHERE
clause under which it should succeed). If the lock doesn't get
written, then you don't have it.
What you _DON'T_ do, is see if the lock is already there before trying
to write one. No need and provides the possibility for another user,
using the same code, to be interleaved.
Also, no need for transactions at this stage too.
You put the lock on (if you are allowed to). Now you can edit and
re-edit the row until you've finished.
This technique is described quite well in
One of the important aspects to using semaphores is that the process
to set (and either succeed or fail) must not be interrupted, hence why
you don't try to read the presence of the lock before setting it.
I hope that helps some.
I used to develop using an old DOS based 4GL called Sage Retrieve 4GL
(prior to that it was called Sage Skybase). This uses a modified
D-ISAM db structure and semaphores for locking. You'd try to lock a
record and process the failure. Quite easy really.
By extending this concept to include an expiry time within the lock,
you've got your auto-unlock feature written.
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php