ID: 12267
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0.6
New Comment:
I would tend to think that :
- make the file session handler race safe- make the mm session handler race safe
- make the a MySQL session handler race safe
- make the a PostgreSQL session handler race safe
- make whatever other session handlers race safe
- ...
...can become code functionnality duplication. No ?
Solving the problem for all handlers by locking the session at a higher level would
appear to me as the most reliable and elegant solution. But I have to admit I don't
know the internals of php to know if it is possible or not.
I'm really surprised, because when I saw the session_end and session_readonly
documentation, I thought that proper locking was made (or at least would be made at
some point) in sessions, but your are explaining to me that this is not the case... so
I have to admit I don't really understand what I should do...
Quote from http://www.ca.php.net/manual/en/function.session-end.php :
<< [...]as session data is locked to prevent concurrent writes only one script may
operate on a session at any time >>
- For the mm handler, is a fix planned ?
- Is there a session handler which would be race safe (files ?) ?
Previous Comments:
------------------------------------------------------------------------
[2001-07-20 08:31:31] [EMAIL PROTECTED]
Comments from Sascha Schumann on the php-dev list:
> The fact is a similar problem is happening with the mm module,
> but here I can't insert error_log to be sure... is this session
> handler "race safe" ?
Nope.
> And I'm surprised that this concurrency issue has to be solved
> on a per handler basis : isn't it functionnality duplication ?
> isn't this a tricky trap for handler programmers ? is this
> mentionned in the documentation ?
Locking a record in your database is not duplication of
functionality.
------------------------------------------------------------------------
[2001-07-20 08:30:33] [EMAIL PROTECTED]
Comments on the php-dev list, by Sascha Schumann:
> This "solved" the problem and I concluded the bug was only due to my fault
> : I should have locked my session table (or row...) to avoid race
> conditions and concurrency problems.
That is right. The session storage handlers have to perform
locking themselves, if they are supposed to be suited for
concurrent accesses.
------------------------------------------------------------------------
[2001-07-19 16:57:40] [EMAIL PROTECTED]
The fact is a similar problem is happening with the mm module, but here I can't insert
error_log to be sure... is this session handler "race safe" ?
And I'm surprised that this concurrency issue has to be solved on a per handler basis
: isn't it functionnality duplication ? isn't this a tricky trap for handler
programmers ? is this mentionned in the documentation ?
------------------------------------------------------------------------
[2001-07-19 15:49:12] [EMAIL PROTECTED]
Sorry for the layout, my 2 columns are broken.
I also changed the 'Type' of the bug to 'Session related'.
------------------------------------------------------------------------
[2001-07-19 15:47:46] [EMAIL PROTECTED]
While testing a php apllication, I found that I had some trouble with session
variables (php4 native sessions, not phplib's crappy ones), at this point I was using
a custom MySQL session handler (with session_set_save_handler).
After adding some error_log calls in my custom session handler functions, I managed to
see that the problem was coming from the fact that a session was reopened before the
current one was written to the database :
(in chronological order)
request A request B
HTTP request A is made on page1.php
session open by session_start:
session variable A equals 0
request A is being treated:
session variable A is set to 1
redirection is made with header()
to page2.php ------------------> request B is made on page2.phpA
exit()
session open by session _start
session variable A equals 0
treatment made by my application:
no change to make to variable A if
variable A is 0
php saves the session
=> A is stored with value 1 exit()
php saves the session
=> A is stored with value 0
And in the end, A ends up being 0, which is not what it should be.
I found a way of making the bug go away (for a moment) : make a sleep(2) in my session
'open' handler. :)))
This "solved" the problem and I concluded the bug was only due to my fault : I should
have locked my session table (or row...) to avoid race conditions and concurrency
problems.
Then I thought that such a locking should have been done by the php session layer
itself, because this issue is common to all session handlers you can use or define.
And I found in the online documentation session_end and session_readonly which
seemingly were tackling with similar concurrency issue, and I concluded this was
worked on and would probably be solved in some next release, but php 4.0.6 doesn't
solve the problem, and the session_end and session_readonly functions - though they
appear in the documentation - are not even appearing in the CVS code.
So my question : is this really a known issue ? is a fix for this planned soon ?
Thank you !!
------------------------------------------------------------------------
Edit this bug report at http://bugs.php.net/?id=12267&edit=1
--
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]
