Is there any way to disable the session locking in PHP while using the default session handler?
[EDIT:] Or is there at least a way to restart a session after calling session_write_close()? session_start() does not work if any output is already sent to the browser.
You don't want to disable it... If you do, you'll potentially run into all sorts of weird issues where you login on one window, be logged out on another and then wind up in an inconsistent state... The locking is there for a reason...
Instead, close the session very early if you know you are not going to write to it in that request. Once you start it, you'll be able to read from it for the whole request (unless you re-start it, or do some other special things) even after you call session_write_close. So what you would do, is check the request to see if it's a write request, and if it's not, just close it right after opening it. Note that this may have some adverse affects if you later try writing to the session (For Captcha or CSRF protection or something else), so use with caution...
But instead of trying to get around it, I would put my effort into either shortening the request lengths (to reduce lock contention), or making cookieless requests for those requests that don't need the session at all...
I had a report page that took over 2 minutes (over 80 AJAX requests). I got it down to under 30 seconds by removing session-locking. Yes, heaven forbid you remove file locking, because then you have race conditions. And if you don't understand race-conditions and you don't know what the effect would be on your sessions...then do NOT remove file-locking. However, if you, knowing what data that is in your sessions, and knowing what race-conditions do, feel that there is no data that could be adversely affected by race conditions which would create a bug...you know your environment better than anyone else does, so go for it.
MySQL, REDIS, and Memcache
Also, note that if you switch to MySQL for session management, there's a 99% chance, IMHO, that you do NOT lock the row from the time you read to the time you write. So, using MySQL you still have the same race conditions (or locking problems if you decide to lock the row).
Based on the information I could find, people who use PHP Redis are using a non-locking application that is prone to race conditions...as per the following thread...and they cite speed as one of the reasons they like this "feature":
https://github.com/phpredis/phpredis/issues/37
Memcached didn't support session locking until version 3.0.4...so it was also--initially--prone to race conditions.
Clearly, with the success of these options, race conditions are not the biggest problem that programmers face.
Ultimately the Issue Is
ALL concurrent requests will ALWAYS be subject to race-conditions UNLESS you do file locking, at which point they are not concurrent requests anymore.
The important thing about Sessions and Locking vs. Concurrency and race conditions is to know your application, know if a race condition could break your application...and devise a solution that fits YOUR application. If all you do is store the userId in the session and read it on all subsequent requests, you probably don't need to worry about race conditions. If you store an elaborate history of data that will break if things happen out of order or data might be lost, then lock the file between reading and writing and try to do your write as quickly after the read as possible to limit the amount of time the file is locked.
The Best Option
A session-less API will, however, be much better for concurrent requests. However, if you don't have time to refactor to such an API...then read-on.
A Stop-Gap Solution to keep using PHP session files and stop locking
To continue using PHP sessions the default way, to stop locking, and basically have a very quick solution to a complex problem, you can implement the PHP website's example implementation of a SessionHandler.
I have the below code running in a production environment for a site with tens of thousands of connections per minute, and I haven't had any problems with race conditions yet, but I also don't store data that a race-condition could break. This code, as I said, got one report from over 2 minutes down to under 30 seconds...and it took a couple of minutes to implement. No MySQL schema to create, no Memcache or Redis to install.
This is, to a letter, the example implementation provided on PHP's documentation (http://php.net/manual/en/class.sessionhandlerinterface.php), and it doesn't lock the session file when it reads it.
NOTE As Anther pointed out in this comments, this will not work in a distributed system unless you save the file to a single server.
<?php
class MySessionHandler implements SessionHandlerInterface
{
private $savePath;
public function open($savePath, $sessionName)
{
$this->savePath = $savePath;
if (!is_dir($this->savePath)) {
mkdir($this->savePath, 0777);
}
return true;
}
public function close()
{
return true;
}
public function read($id)
{
return (string)@file_get_contents("$this->savePath/sess_$id");
}
public function write($id, $data)
{
return file_put_contents("$this->savePath/sess_$id", $data) === false ? false : true;
}
public function destroy($id)
{
$file = "$this->savePath/sess_$id";
if (file_exists($file)) {
unlink($file);
}
return true;
}
public function gc($maxlifetime)
{
foreach (glob("$this->savePath/sess_*") as $file) {
if (filemtime($file) + $maxlifetime < time() && file_exists($file)) {
unlink($file);
}
}
return true;
}
}
In PHP 5.4+, using it is as simple as setting the handler before you start your session:
$handler = new MySessionHandler();
session_set_save_handler($handler, true);
session_start();
For lower versions of PHP, you can still do it via function calls...see the PHP docs.
This is a rather old question which I came across while researching session handlers, however the answer is yes it is possible - but not using the default handler (without deep hacking into the filesystem to disable locking).
I have come across the same issue. The important thing to note is that you really must know exactly the consequences of disabling locking!
My solution is part of a larger extension to the session handling mechanism - the Stackable Session Handler which includes storage compatible with the default handler and (optionally) non-blocking session reads and writes.
You can restart the session by recalling session_start() after session_write_close(). However this will cause multiple SIDS. I resolve this by removing the multiple SIDS from the header before the output is flushed.
See this example: https://gist.github.com/CMCDragonkai/6912726#file-nativesession-php-L254
There is no way of disable locks from php sessions. It's a real nighmare use case of locking. Only way to get rid of sessions and/or php. As a temporary solution you may want to use riak session handler: https://github.com/zacharyfox/riak-php-sessions it's lock free, and it's working.
Last versions of memcached session handler also introduces locking for some insane reasons and no way to disable it.
If PHP is not handling requests asynchronously even after calling session_write_close, it may just be xdebug. I don't know if that is your issue, but I keep getting tripped up by this and driving myself crazy over it so I thought I'd post it if anyone else is having the same issue :)
Other than using session_write_close() ? None that I know of.
