Hi Sascha,
Thanks for your answer, I now understand better why locking is not made
at a lower level. And you are right, I don't have a proposal for general
locking, I don't know php nor C nor Apache enough.
However, I really think it would be better to document this somewhere.
If it is a technical choice for performance reasons, it should be said
so. It may also be precised which session handlers are race safe, and
which are not. Even more, documentation should avoid suggesting sessions
are locked if is only the case for file based sessions.
I would really accept a reasonable performance tradeof to have low level
locking of sessions, because in some cases that's what I would prefer
(may people use MySQL - which doesn't offer row level locking - as a
backend). What about something optionnal which would make a general
locking optionnal, perhaps enabled by default except for handlers
declaring that they will handle locking themselves, I don't know...
Currently my choice is whether to rely on file based sessions - which
are slow and not distributed - or to adapt my MySQL session handler, but
this won't be clean since without row level locking, I'll have a race
anyway, and deadlocks if I'm not careful, (and worse performances, but
well, that's okay, you have to pay somewhere to have good reliability).
I have to admit I'm very surprised this doesn't qualify a bug : this
race condition can really be a problem in some applications : in one of
my tests, I even saw two completed requests happen before an opened
session be saved :
request A starts
session opens
...
exit() ... request B starts
session open
...
exit()
session saved
...
request C starts
session open
...
exit()
session saved
...
session saved
(of course for the same session identifier)
The delay between request A exit() and the corresponding session save
was about 2.5 seconds.
I'm really sorry I don't have the competencies (nor time) to help on low
level stuff for this problem. I would really be happy to help, and I
feel a bit sad to criticize while I'm not able to commit code. Still, I
believe users expectations are expressed somewhere.
-tom
--
== Thomas.Morin @webmotion.com SysAdmin/R&D
== Phone: +1 613 731 4046 ext113 \Fax: +1 613 260 9545
== PGP/keyID: 8CEA233D
== PGP/KeyFP: 503BF6CFD3AE8719377B832A02FB94E08CEA233D
--
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
