Bug #12267 Updated: Session (concurrency ?) problem

ID: 12267 Updated by: kalowsky Reported By: thomas.morin@webmotion.com Status: Open Bug Type: Session related Operating System: Linux PHP Version: 4.0.6 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2001-07-20 08:30:33] 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-19 16:57:40] thomas.morin@webmotion.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-19 15:49:12] thomas.morin@webmotion.com 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] thomas.morin@webmotion.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 !! ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=12267&edit=1