|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #63278 Session locking is not described at all
Submitted: 2012-10-14 19:41 UTC Modified: 2013-01-16 19:26 UTC
From: sven at rtbg dot de Assigned:
Status: Duplicate Package: Session related
PHP Version: Irrelevant OS: any
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: sven at rtbg dot de
New email:
PHP Version: OS:


 [2012-10-14 19:41 UTC] sven at rtbg dot de
From manual page:
Session locking is not described at all. The callbacks for "open" and "close" must aquire a write lock on the ressource that stores the session data. If this is not done, race conditions will destroy the data.

The internal files handler gets it right.

The Example #2, which reimplements this handler, gets it wrong!

I don't know about any other internal save handler, like sqlite or memcached.

This one is a duplicate of Bug #55624, but with better explanation and more code. :)

Test script:
Please see

Expected result:
When running the script from the expected behaviour is that all three iframes get filled one after another, with 1 second break between each.

The last response should list all three subrequests and the master request in the var_dump().

Actual result:
Using the example #2 code, all iframes get filled after 1 second, and all of them only report the master request and its own subrequest in the dump.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-01-16 19:26 UTC]
Dup bug #55624
 [2013-01-16 19:26 UTC]
-Status: Open +Status: Duplicate
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 16 07:01:28 2024 UTC