Great explanation, Richard!
I think I understand the concept now. I'll study it a little and try to
implement it.
Thanks!
- Ron
On 1/28/2010 5:47 AM, Richard Quadling wrote:
> On 27 January 2010 17:20, listread<listread@cze.com> wrote:
>
>> Richard,
>>
>> I think I need to learn about semaphores! Any suggestions for a good
>> tutorial?
>>
>> One of the things we want to do is exclude locked records from a query.
>> Will semaphores provide for that?
>>
>> Thanks!
>>
>> - 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
>>> itself).
>>>
>>> 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
> semaphores.
>
> 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
> http://en.wikipedia.org/wiki/Semaphore_(programming)
>
> 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.
>
>
>
|