Automatic logoff
in [Databases]
|
Prev: result set in php pagination
Next: Random pick
From: listread on 28 Jan 2010 15:24 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(a)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. > > >
From: listread on 28 Jan 2010 15:29 Richard, One more question (for now): Are there advantages to using a separate table for locking, rather than specifying a lock column in the table you want to lock the row in? - Ron On 1/28/2010 5:47 AM, Richard Quadling wrote: > On 27 January 2010 17:20, listread<listread(a)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. > > >
From: Richard Quadling on 28 Jan 2010 16:49
On 28 January 2010 20:29, listread <listread(a)cze.com> wrote: > Richard, > > One more question (for now): Â Are there advantages to using a separate > table for locking, rather than specifying a lock column in the table you > want to lock the row in? > > - Ron > > On 1/28/2010 5:47 AM, Richard Quadling wrote: >> >> On 27 January 2010 17:20, listread<listread(a)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. >> >> >> > > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I've never done any studies on this. I've always used a separate table. I suppose one reason is that you don't touch the live data unless you have the semaphore. Also, the additional columns would need to be on every table where semaphoring is required. So, having all the locks in a lock table seems right. The lock table should be small, whereas the data it is locking could be very big. -- ----- Richard Quadling "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 |