ID: 12267
User updated by: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

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 ?

Previous Comments:

[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
                                           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 

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

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to