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! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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 Apr 19 07:01:26 2025 UTC