PHP & Sessions: How to Disable PHP Session Locking

Avoid locking session PHP in Symfony

This situation is not unique to Symfony. You can experience exactly the same thing in almost any other PHP based web app making use of sessions and parallel requests from the same client.

A prime example is WordPress where there are multiple plug-ins needing an update. If you click the AJAX update link on all the plug-ins at the same time they won't all update together in parallel. (The first plug-in you clicked update on needs to finish before the 2nd plug-in starts updating, etc.)

Likely duplicate: How to process multiple parallel requests from one client to one PHP script

Part of the problem that can be Symfony specific is that it really really wants to have a session available, because parts of the framework (such as the security bundle) require a session. When the session is file based you hit a limit because you can't have multiple write handles to the same file at any given time, which is a caveat imposed by the underlying operating system rather than PHP. -- This is not a problem with memory handles, which is why memcached solved this issue for you.

Is there any reason why you want to use file based sessions instead of memcached? There are plenty of reasons why memcached is a better choice, as discussed here: Session VS File VS Memcache for a Cache in PHP?

PHP session locking and using Memcache to store sessions

The php-memcached extension supports session locking

http://us3.php.net/memcached

http://us1.php.net/manual/en/memcached.sessions.php

The memcache and memcached extensions look syntactically similar so it may not be too much of a headache to give it a try. (memcached has a stable version 2.1.0 released 2012-08-07).

---

If you are set on using memcache 2.2.7 you will most likely have to implement the lock yourself by setting some "session_is_locked" variable in your session and then releasing/unsetting it when the script is done writing to the session. Then you'd always need to check if that variable is set before continuing with any scripts which write to the session.

How to disable PHP session cookie?

err its possible to override the default settings of your host by creating your own .htaccess file and here's a great tutorial if you havent touched that yet
http://www.askapache.com/htaccess/apache-htaccess.html

or if you're too lazy to learn
just create a ".htaccess" file (yes that's the filename) on your sites directory and place the following code

SetEnv session.use_cookies='0';

Is there some kind of performance (or other) punishment for using session_start() but not really using the session super-array?

It's not really a question of how much overhead it causes, as far as why sessions aren't started by default. There are tons of possible PHP applications that have nothing to do with session variables (including any CLI use!), and therefore, on principle it shouldn't be automatically started. Establishing an idle database connection ("immensely useful!") also doesn't create silly overhead. It's still not done by default. Resources should be available, but uninstantiated.

The main performance impact caused by starting a session, with or without ever using it, basically involves (quoting from the manual on session_start()):

• PHP will call the open and read session save handlers. ... The read callback will retrieve any existing session data (stored in a special serialized format) and will be unserialized and used to automatically populate the $_SESSION superglobal when the read callback returns the saved session data back to PHP session handling.

This typically means disk access to look up and read the serialized session data. Even if it's empty or non-existent. (It will not be created until $_SESSION variables are used; but you won't know if it's there without trying!) Also: your session ID is typically stored in a cookie. Want session? Make a cookie, take a cookie, pass a cookie, read a cookie, etc. pass/read on each page load. Unnecessary baking and trading, and we'd rather avoid redundant HTTP traffic.

Aside that, there's a strange and wonderful thing called session locking that can make you scractczch your head a lot and wonder why you can't load long-running scripts on your site in two tabs simultaneously, even when you've double-damned-configured your Apache, MySQL and the rest to handle concurrent connections and/or space alien armadas on steroids. Without session locking, you could. (Alas, debugging long-running scripts with sessions on!)

Significantly, this will haunt you with concurrent AJAX requests to PHP scripts with sessions; they'll be sequentially processed instead. There are ways to overcome session locking delays, but the default behavior blocks parallel execution, and requests are queued, and it's rather annoying but a necessary evil to prevent race conditions and session corruption (read more).

So much for the obvious performance/quirks side. In terms of customizing how things work, there are functions that may be called before session_start(), such as session_name() (for named sessions). The session_start function itself (as of PHP 7) takes an optional array of session parameters which you couldn't use, were the session started by default.

If you look at the link above, you'll notice that there is in fact a session auto-start option in php.ini session configuration:

session.auto_start boolean

session.auto_start specifies whether the session module starts a session automatically on request startup. Defaults to 0 (disabled).

There are some related cautions in PHP Intro to Sessions on the auto_start option:

Caution If you turn on session.auto_start then the only way to put objects into your sessions is to load its class definition using auto_prepend_file in which you load the class definition else you will have to serialize() your object and unserialize() it afterwards.

If you are certain that you always want to use sessions, the simplest move would be to create a bootup file that you require at the beginning of files that use sessions; add the path to the file into your include path; and then simply <?php require 'sessions.php' before your main code begins.

The session bootup file could also have some of your own session-handling functions, etc. relevant standard material. This route would give you more freedom than the auto-start option, plus a way to implement other options and functionality across all your session-using code. You shouldn't rely on the auto-start in any case, in case you ever want to create code that can be easily deployed into environments with default PHP configuration!

---

Related Topics