> -----Original Message----- > From: Richard Quadling [mailto:rquadling@xxxxxxxxxxxxxx] > Sent: Thursday, January 28, 2010 3:48 AM > To: listread > Cc: php-db@xxxxxxxxxxxxx > Subject: Re: Automatic logoff > > On 27 January 2010 17:20, listread <listread@xxxxxxx> 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. > > > -- > ----- > Richard Quadling An intersting synopsis of "Semaphores". I've done similar things in the past, but never knew this is what I was doing. LOL. Just like I've built an uber XML parser/editor and didn't know that I actually built a "Factory". Ahhh... good old data structures -- they didn't teach these things when I was in college (20+ years ago). I particularly found this part interesting as I hadn't considered this, "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." I am assuming (and correct me if I'm wrong) as you will get a race condition (on a sufficiently large system) wherein, two users check "is there a directory lock", and the system responds "No" to each, and then the code attempts to create a directory. Then one of them gets a lock granted (i.e a directory) and since 'there can be only one' [highlander reference] the other one THINKS they got the lock (too). Doh! The wiki page is also interesting and I'd always heard these terms, but never really knew what they were in a practical sense: "A mutex is a binary semaphore that usually incorporates extra features, such as ownership, priority inversion protection or recursivity. The differences between mutexes and semaphores are operating system dependent, though mutexes are implemented by specialized and faster routines. Mutexes are meant to be used for mutual exclusion (post/release operation is restricted to thread which called pend/acquire) only and binary semaphores are meant to be used for event notification (post-ability from any thread) and mutual exclusion. Events are also sometimes called event semaphores and are used for event notification." And this also helped to clarify: http://stackoverflow.com/questions/62814/difference-between-binary-semaphor e-and-mutex -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
