|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #55624 session_set_save_handler should mention locking
Submitted: 2011-09-06 17:41 UTC Modified: 2016-10-17 21:30 UTC
Avg. Score:3.5 ± 1.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: Assigned: yohgaki (profile)
Status: Closed Package: Session related
PHP Version: Irrelevant OS:
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:
New email:
PHP Version: OS:


 [2011-09-06 17:41 UTC]
I've learned a couple of years ago the hard way that the default session handler 
uses locking(flock) for locking the session files, so there couldn't be two 
concurrent script execution with the same session id.
However when people started using their own session handlers, they usually get the 
concept from the example in the php manual, which doesn't mention that what are 
the pros/cons for serializing the session execution.
I would suggest to add the flock call to the example implementation, and add a 
note about the potential problems if no locking mechanism is implemented 
(potential dataloss, concurrent requests can overwrite each others data, that 
there is no guarantee that two ajax request will be served in the same order, 

heck, even the memcache ext (
package=memcache) was bitten by this problem.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-10-17 11:21 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: yohgaki
 [2016-10-17 11:40 UTC] narf at devilix dot net
Why is this closed with a link to ?

The issue was about adding flock() calls to the examples on session_set_save_handler() ([1]) and warning them against the dangers of NOT using locks.
It was NOT about scaring users away from locking with talks about DoS attacks.

* [1]
 [2016-10-17 11:56 UTC]
"Session data is locked to avoid races by default. Locking is mandatory to keep session data consistent across requests."

Isn't this enough? 
I agree this isn't enough for beginners, though.
 [2016-10-17 12:01 UTC] narf at devilix dot net
That may be enough on the new section you've created, but this issue is explicitly about the examples on

Many users use that as a reference or just straight copy-paste from there, and there are zero mentions of locking on that page.
 [2016-10-17 18:26 UTC]
BTW, I'm going to fix session save handler's mess soon, object interface interface especially.

IIRC, I've written full procedural save handler implementation many years ago that includes exclusive locks in the manual that includes precise return data types for each handler. This was removed from the manual somehow, and replaced by OO only description which lacks many aspects. I might have written this in somewhere else. It's very long time ago.

Current manual page lacks create_sid, validate_sid, update_timestamp handler description, even if validate_sid handler implementation is mandatory absolutely. Since I implemented validate_sid, I'm certain that I've written manual for this. The manual page is gone also.

I shall write complete manual page when save handler mess is corrected.
 [2016-10-17 21:30 UTC]
Added minimum description by commit 340522
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 21 02:01:29 2024 UTC