ID: 12267
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

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 <[EMAIL PROTECTED]>
     To: 
         <[EMAIL PROTECTED]>
     CC: 
         <[EMAIL PROTECTED]>




    This should not be a bug report.  Please respond by email.



Previous Comments:
------------------------------------------------------------------------

[2001-07-20 11:15:36] [EMAIL PROTECTED]

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 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'.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/?id=12267


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]

Reply via email to