Automatic logoff
in [Databases]
|
Prev: result set in php pagination
Next: Random pick
From: Chris on 26 Jan 2010 17:03 listread wrote: > Bruno, > > Thanks for the heads up on the php configuration. I'll check that out. > > We also need to write some data to a database, things like logout time. > That means running a script for some other php code. There are probably a number of situations where the onUnload thing won't work including browser crashes, some browsers may not support it, will it work if you have multiple browser tabs open and close one (something you'll have to research) etc, so be aware that you're not going to get this 100% right. If you just want the timing, I'd do it the other way. Each time their session is checked (on page load), update the "end" time. In db terms: update session set logout_time=NOW() where session_id='X'; That way you're always going to get at least an idea of how long their session lasts but you won't get "reading time" on the page (ie it takes me 2 mins to read something on the page, the logout_time will be 2 minutes before I actually close it). -- Postgresql & php tutorials http://www.designmagick.com/
From: listread on 27 Jan 2010 08:01 Chris, Yes, I can see how your suggestion would be good for approximating the length of a visit, but my issue is more specific and technical... We will have users updating database records. We want to lock a record while it is being worked on and release it once the user is finished or otherwise leaves the site. That's why we want a graceful exit. Maybe I should start a new thread about locking db records? - Ron On 1/26/2010 4:03 PM, Chris wrote: > listread wrote: >> Bruno, >> >> Thanks for the heads up on the php configuration. I'll check that out. >> >> We also need to write some data to a database, things like logout >> time. That means running a script for some other php code. > > There are probably a number of situations where the onUnload thing > won't work including browser crashes, some browsers may not support > it, will it work if you have multiple browser tabs open and close one > (something you'll have to research) etc, so be aware that you're not > going to get this 100% right. > > If you just want the timing, I'd do it the other way. > > Each time their session is checked (on page load), update the "end" > time. In db terms: > > update session set logout_time=NOW() where session_id='X'; > > That way you're always going to get at least an idea of how long their > session lasts but you won't get "reading time" on the page (ie it > takes me 2 mins to read something on the page, the logout_time will be > 2 minutes before I actually close it). >
From: Richard Quadling on 27 Jan 2010 09:14 2010/1/27 listread <listread(a)cze.com>: > Chris, > > Yes, I can see how your suggestion would be good for approximating the > length of a visit, but my issue is more specific and technical... > > We will have users updating database records. Â We want to lock a record > while it is being worked on and release it once the user is finished or > otherwise leaves the site. > > That's why we want a graceful exit. > > Maybe I should start a new thread about locking db records? > > - Ron > > On 1/26/2010 4:03 PM, Chris wrote: >> >> listread wrote: >>> >>> Bruno, >>> >>> Thanks for the heads up on the php configuration. Â I'll check that out. >>> >>> We also need to write some data to a database, things like logout time. >>> Â That means running a script for some other php code. >> >> There are probably a number of situations where the onUnload thing won't >> work including browser crashes, some browsers may not support it, will it >> work if you have multiple browser tabs open and close one (something you'll >> have to research) etc, so be aware that you're not going to get this 100% >> right. >> >> If you just want the timing, I'd do it the other way. >> >> Each time their session is checked (on page load), update the "end" time.. >> In db terms: >> >> update session set logout_time=NOW() where session_id='X'; >> >> That way you're always going to get at least an idea of how long their >> session lasts but you won't get "reading time" on the page (ie it takes me 2 >> mins to read something on the page, the logout_time will be 2 minutes before >> I actually close it). >> > > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > 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. -- ----- 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
From: listread on 27 Jan 2010 12:20 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. > >
From: Richard Quadling on 28 Jan 2010 06:47
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. -- ----- 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 |