If your developing a new website and want to ensure its scalable sessions can be a sticking point. Since PHP sessions by default are local only you decide to use the session handlers to build your own database driven sessions.
There are a couple problems you may run into with this approach and most database driven examples you may use to base your session code off.
These problems can pretty much be summarized into a single sentence.
So I need to create a portal site, where we will require multiple frontends. As most portal's we need to store some state information inside a session. We also need to show how many users are online, but more importantly be able to filter searches in the member database by who is online (we do not need to filter by how long the last site interaction as been, but you never know with changing requirements).
Now in order to filter by users in the member search, we need to have some information about active sessions by user id inside MySQL database. But if we were to put the entire session data inside the database we would have to hit the master on every request to update the session timeout. More importantly we would have to deal with replication lag.
There are many reasons to utilize sessions when creating a web-based application using PHP. Session information, by default, is stored in a file on your web server. But what if that becomes a problem? In this article, I'll talk about why you might want to move your PHP sessions to a database, and show you how to do it.
One may think changing PHP session handler from file based to database driven is fully transparent. In many cases it is, sometimes however it may cause some unexpected problems as happened to one of our customers.
If you use file based sessions PHP will lock session file for whole script execution duration, which means all requests from the same sessions will be serialized on PHP level, which means they also will be serialized for single user on database level. If you change to store PHP sessions in MySQL instead this effect may be no more true and you may have number of requests executing for the same session at the same time. First of course means you may have your session data damaged because you will have lost session variables update from one of the script, in addition however you may run into database related issues of modifying user profile or other user/session related data in parallel, if you do not use transactions or lock tables.
So how you can get back your old file based session behavior with MySQL Sessions ?
A while back I was reading an article that Chris Shiflett wrote about sessions, it is rather in depth and very informative. He goes into all the details about the HTTP protocol and how it is stateless, how the developer has to add state at the application level. He goes on to talk about how PHP handles storing sessions and why the out of the box solution that PHP offers is not very secure. I suggest you read Chris’s article to better understand how the internal PHP sessions work. One aspect that I dislike about the internal PHP sessions is that they are stored in files on the hard disk (usually /tmp/) by default. This means anyone with access to the machine has access to read the session data. I prefer to store my session information in the database to add an extra layer of security.
We had a bit of a sticky situation here at the Centresource stomping grounds this past couple of weeks. We have a server with a multitude of environments served via our Apache webserver. It’s a fairly simple setup: we have a virtualhost devoted to development environments for all of our software developers, and then a plethora of virtualhosts for the various web-based applications we use: some home-brewed, some OSS web applications we use for various business functions (CMS, CRM, Groupware, etc..).
Here you have it. The tutorial that you were waiting for! Welcome to the concluding part of the series “Maintaining the state of applications with PHP sessions.” In several tutorials, this series goes through the key points of managing sessions in PHP, and explores some of their most advanced features, such as developing user-defined session storage modules and using session handling objects.
Here we are again. This is part two of the series “Maintaining the state of applications with PHP sessions." In three parts, this series ranges from the basics of session management in PHP, such as creating, registering session data, and destroying sessions, to exploring advanced concepts, like working with different session storage modules and creating custom session handling objects.
While the default session storage mechanism is adequate for many PHP developers, you might find yourself wanting to modify its behavior from time to time. One of the most common reasons for wanting to change the default behavior is to store sessions in a database rather than the filesystem.
In PHP, session management is used to help web applications maintain their state across several HTTP requests when needed. In this first part of a series, you will learn the basics of the PHP built-in session mechanism, as well as some of its many useful functions.
