In what scenarios is it better to use tables for user sessions rather than native sessions?

Question

That's about all that I need to ask

I am dealing with a site right now and I can't see a really significant difference in storing my sessions in a database table over and not doing so.

Answer 1

There are a couple reasons why I sometimes store session data in a DB. Here are the biggest two:

1. Security Concerns on a Shared Server If you're running on a shared server, the chances are that it's easy for other users of the server to meddle their way into your temp directory and have access to the session data you have stored there. This isn't too common, but it can happen.
2. Using Multiple Servers If you're upscaling and using more than one server, it's best to store the session data in a database. That way the data is easily available throughout your entire server stack (or farm depending on how big you're going). This is also attainable through a flat file system, but using a database is usually a more elegant, easy solution.

The only thing I can think of for not using a database is simply the number of queries you'll be running. For each page load, you'll have an extra query to gather the session data. However, one small extra query shouldn't make that much difference. The two points I outlined above outweigh this small cost.

Hope that helped a bit.

Answer 2

On a shared host when you have no control over who can access the directory where session files are stored. In this case storing sessions in the DB can offer better security.

And one scenario with which I have no experience myself, but I believe is a realistic scenario:
On a loadbalanced server farm where subsequent requests of one user can be dispatched over multiple servers. In this case you could choose to have one central DB server. In such a scenario, if you wouldn't have such a centralized session repository, session data of users would get lost because they could switch servers per request.

Answer 3

There is a huge difference when you are using several servers, with a load-balancing mecanism that doesn't guarantee that a given use will always be sent to the same server :

• with file-based session, if the user is load-balanced to a server that is not the same as the one which served the previous page, the file containing its session will not be found (as it's on another server), and he will not have his session data
• with databased-based or memcached-based sessions, the session data will be available from whatever server -- which is quite nice actually, in this quite of situation.

There's also a difference when you are using some shared hosting : with file-based session, if those are placed in the "temporaty" directory of the server (like /tmp), anyone might read your sessions files, depending on the configuration of the server. With DB-based sessions, this problem doesn't exists, as each user will have a different DB and DB user.

Answer 4

In addition to the above posts:

• Database sessions (when session table is of Memory type) are faster.
• When using file-based sessions, session file is locked until script ends. So, user cannot have two working at the same time scripts on server. This matters for example, when you write a download server. User downloads a file, script sends file to him, leaving session file locked. And user cannot at the same time browse the contents of file archive.