php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #12267 Session (concurrency ?) problem
Submitted: 2001-07-19 15:47 UTC Modified: 2001-07-20 15:24 UTC
From: thomas dot morin at webmotion dot com Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.0.6 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: thomas dot morin at webmotion dot com
New email:
PHP Version: OS:

 

 [2001-07-19 15:47 UTC] thomas dot morin at webmotion dot com 
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 !!

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-07-19 15:49 UTC] thomas dot morin at webmotion dot com 
Sorry for the layout, my 2 columns are broken.
I also changed the 'Type' of the bug to 'Session related'.
 [2001-07-19 16:57 UTC] thomas dot morin at webmotion dot com 
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-20 08:30 UTC] kalowsky@php.net 
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-20 08:31 UTC] kalowsky@php.net 
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 11:15 UTC] thomas dot morin at webmotion dot com 
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 ?) ?
 [2001-07-20 15:24 UTC] kalowsky@php.net 
marked as bogus according to Sascha Schumanns email pasted below:

Subject: 
         Re: [PHP-DEV] Bug #12267 Updated: Session (concurrency ?) problem
    Date: 
         Fri, 20 Jul 2001 21:22:39 +0200 (MEST)
   From: 
         Sascha Schumann <sascha@schumann.cx>
     To: 
         <thomas.morin@webmotion.com>
     CC: 
         <php-dev@lists.php.net>




    This should not be a bug report.  Please respond by email.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Jan 04 08:01:28 2025 UTC