ID: 12267 Comment by: chat-masturbation1566 at hotmail dot com Reported By: thomas dot morin at webmotion dot com Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.0.6 New Comment:
<a href=http://black-foodmpegsite.da.ru>chat masturbation</a> Previous Comments: ------------------------------------------------------------------------ [2001-07-20 15:24:06] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ [2001-07-20 11:15:36] 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 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] 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 ? ------------------------------------------------------------------------ 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/12267 -- Edit this bug report at http://bugs.php.net/?id=12267&edit=1
