Has anyone considered a way to run a script or automatically access a
php page when a user leaves a site without logging off?
The idea is to gracefully end that user's session.
Thanks!
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Jan 25, 2010 at 1:48 PM, listread
> Has anyone considered a way to run a script or automatically access a php
> page when a user leaves a site without logging off?
>
> The idea is to gracefully end that user's session.
>
> Thanks!
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
You can try using an ajax call paired with the js onunload function to
call the server. The other option is to time the user out via cron on
the server after x number of minutes
--
Bastien
Cat, the other other white meat
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
2010/1/25 listread
> Has anyone considered a way to run a script or automatically access a php
> page when a user leaves a site without logging off?
>
> The idea is to gracefully end that user's session.
The built-in garbage collector is not sufficient for your app?
Additionally, you can configure PHP to destroy the session as soon as
the client closes your page.
>
> Thanks!
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
js onunload sounds like a viable option. Will it work if the use just
closes his browser?
Thanks for the tip!
- Ron
On 1/25/2010 12:51 PM, Bastien Koert wrote:
> On Mon, Jan 25, 2010 at 1:48 PM, listread
>
>> Has anyone considered a way to run a script or automatically access a php
>> page when a user leaves a site without logging off?
>>
>> The idea is to gracefully end that user's session.
>>
>> Thanks!
>>
>> --
>> PHP Database Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
> You can try using an ajax call paired with the js onunload function to
> call the server. The other option is to time the user out via cron on
> the server after x number of minutes
>
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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.
Thanks!
- Ron
On 1/25/2010 1:24 PM, Bruno Fajardo wrote:
> 2010/1/25 listread
>
>> Has anyone considered a way to run a script or automatically access a php
>> page when a user leaves a site without logging off?
>>
>> The idea is to gracefully end that user's session.
>>
> The built-in garbage collector is not sufficient for your app?
> Additionally, you can configure PHP to destroy the session as soon as
> the client closes your page.
>
>
>> Thanks!
>>
>> --
>> PHP Database Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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/
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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
2010/1/27 listread
> 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 rec=
ord
> 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 i=
t
>> 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=3DNOW() where session_id=3D'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 be=
fore
>> 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 itse=
lf).
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.
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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
On 27 January 2010 17:20, listread
> Richard,
>
> I think I need to learn about semaphores! Â Any suggestions for a goo=
d
> 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 us=
er
>> in the same session (expired or otherwise).
>> Â c - the semaphore has expired - the other user simply took too lo=
ng.
>>
>> If the semaphore cannot be set it will be because of :
>> Â d - Different non expired session - someone else is editing the r=
ecord.
>>
>> 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 filenam=
e.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.
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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
>
>> 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
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
>
>> 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
=20
> -----Original Message-----
> From: Richard Quadling [mailto:rquadling@googlemail.com]=20
> Sent: Thursday, January 28, 2010 3:48 AM
> To: listread
> Cc: php-db@lists.php.net
> Subject: Re: [PHP-DB] Automatic logoff
>=20
> On 27 January 2010 17:20, listread
> > Richard,
> >
> > I think I need to learn about semaphores! =A0Any suggestions=20
> for a good
> > tutorial?
> >
> > One of the things we want to do is exclude locked records=20
> from a query.
> > =A0Will 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 :
> >> =A0 a - no existing semaphore - no ongoing edits.
> >> =A0 b - the semaphore's session is the same - repeat edits=20
> by this user
> >> in the same session (expired or otherwise).
> >> =A0 c - the semaphore has expired - the other user simply=20
> took too long.
> >>
> >> If the semaphore cannot be set it will be because of :
> >> =A0 d - Different non expired session - someone else is=20
> editing the record.
> >>
> >> When a user saves the row, you just remove the semaphore.
> >>
> >> The semaphores could be in a separate table (rather than=20
> 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=20
> different amount
> >> of time from edit to expiry.
> >>
> >> An entry on a lookup table (just a description) should, in=20
> 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
> >
> >
>=20
> 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.
>=20
> A common technique for "locking" files is to create a folder=20
> called filename.lck
>=20
> A directory can only exist or not.
>=20
> You try to create the directory. If you did, you got the lock. If not,
> someone else has.
>=20
> The same approach should be used for DB locking in this manner.
>=20
> 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.
>=20
> 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.
>=20
> Also, no need for transactions at this stage too.
>=20
> You put the lock on (if you are allowed to). Now you can edit and
> re-edit the row until you've finished.
>=20
> This technique is described quite well in
> http://en.wikipedia.org/wiki/Semaphore_(programming)
>=20
> 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.
>=20
> I hope that helps some.
>=20
> 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.
>=20
> By extending this concept to include an expiry time within the lock,
> you've got your auto-unlock feature written.
>=20
>=20
> --=20
> -----
> 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".=20
Ahhh... good old data structures -- they didn't teach these things when=20
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-semaph=
or
e-and-mutex
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On 28 January 2010 20:29, listread
> Richard,
>
> One more question (for now): Â Are there advantages to using a separ=
ate
> 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
>>
>>>
>>> Richard,
>>>
>>> I think I need to learn about semaphores! Â Any suggestions for a g=
ood
>>> 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.
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On 28 January 2010 21:38, Daevid Vincent
> 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 t=
o
> 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 sin=
ce
> 'there can be only one' [highlander reference] the other one THINKS they
> got the lock (too). Doh!
What happens in code depends upon the code.
If the code doesn't test the result of assigning the lock, then there
is no lock.
Every write will overwrite whatever was previously written if all
users use the same code.
And there is the major flaw of distributed or client initiated semaphoring.
It is entirely possible for you to open up your DB gui tool and amend
the data. Completely bypassing the semaphoring.
So, whilst semaphoring is really useful for long edits, it isn't perfect.
But as long as all code use the same semaphoring logic, then it is fine.
> 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 bina=
ry
> 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 use=
d
> for event notification (post-ability from any thread) and mutual exclusio=
n.
> 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-semaph=
or
> e-and-mutex
>
Ha! Toilets.
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On 1/28/2010 3:57 PM, Richard Quadling wrote:
> On 28 January 2010 21:38, Daevid Vincent
>
>> 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!
>>
> What happens in code depends upon the code.
>
> If the code doesn't test the result of assigning the lock, then there
> is no lock.
>
> Every write will overwrite whatever was previously written if all
> users use the same code.
>
> And there is the major flaw of distributed or client initiated semaphoring.
>
> It is entirely possible for you to open up your DB gui tool and amend
> the data. Completely bypassing the semaphoring.
>
>>>
Would this support the idea of putting a lock column in the table to be
locked? If an admin had cause to go into a table with a DB gui tool,
at least he would see the semaphore as a "warning".
The same table would also simplify code and make the sb more portable.
As for speed, you have to query that (those) records to be updated
anyway at some point - a special lock table would require another query
and if it that lock table was for ALL the other tables in the system, it
would be getting more hits than any one table.
This has been very educational for me - thanks for the discussion.
- Ron
>>>
> So, whilst semaphoring is really useful for long edits, it isn't perfect.
>
> But as long as all code use the same semaphoring logic, then it is fine.
>
>
>> 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
>>
>>
> Ha! Toilets.
>
>
>
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On 29 January 2010 13:43, listread
> Would this support the idea of putting a lock column in the table to be
> locked?  If an admin had cause to go into a table with  a DB gu=
i tool, at
> least he would see the semaphore as a "warning".
>
> The same table would also simplify code and make the sb more portable.
>
> As for speed, you have to query that (those) records to be updated anyway=
at
> some point - a special lock table would require another query and if it t=
hat
> lock table was for ALL the other tables in the system, it would be gettin=
g
> more hits than any one table.
>
> This has been very educational for me - thanks for the discussion.
>
You could easily extend this to be table locking. Assuming that the
key is tableid/rowid, then you would need to include logic to handle
tableid/null to indicate the whole table.
Obviously, you can't put a table lock on if another user has a row or
table lock.
It does get a little more messy, but perfectly doable in a single SQL query=
..
Where you put the lock is pretty much up to you, but the extra columns
have no bearing on the table. They aren't data for that table.
A semaphore table would be small.
You can easily remove all the locks from all the tables/rows simply by
truncating the semaphore table.
The other way around all of this is to not do any locking at all.
Simply log when a row is saved and when you go to save the row include ...
where rows_last_edited_datetime =3D
the_datetime_I_read_when_I_started_editing_the_row
But I don't like that method. It is first saves wins, rather than locking.
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php