Page 1 of 1

storing sessions in DB

Posted: Fri Nov 03, 2006 9:46 am
by GeXus
Would anyone be able to explain why you might store session data in a database? I don't see why that would be beneficial, however I hear about people doing it..

Posted: Fri Nov 03, 2006 10:02 am
by kaszu
If person is using shared hosting to host his website, then saving session in database will prevent third person from seeing what you are saving in session.

This may interest you: http://uk.php.net/session_set_save_handler

Posted: Fri Nov 03, 2006 10:19 am
by RobertGonzalez
It depends on what your needs are as it relates to sessions. Sometimes you want to store values that are common to every page and you want to know that every session var is available to you on every page. Typically when you do this, you take information for the session and store it in a sessions table and match that against a session_id field in the users table.

One other benefit to database sessions is that you are not reliant on a setting on the server to handle it and you can adjust the timing a little better for garbage collection and such.

Posted: Fri Nov 03, 2006 11:07 am
by GeXus
You would still need to have one active session variable, which would be the session_id or whatever to query the DB is that right?

Posted: Fri Nov 03, 2006 11:17 am
by RobertGonzalez
Absolutely. The nice thing, too, about DB sessions is that the last session information is stored and accessible. So say you want your users to 'Stay logged in', they would be able to using DB sessions. It is a little harder using native PHP sessions.

Posted: Fri Nov 03, 2006 12:20 pm
by GeXus
I see.... but even if you have data stored you still have to maintain that one active session_id... so I guess if you have to maintain the one active session, why not maintain the rest, if need be? Also, quite often (for me at least) I only ever have one session, that would be a user_id.. so in that case you wouldn't store that in the DB.. because there would be no way of knowing who's is who's.... does that make sense?

Posted: Fri Nov 03, 2006 12:33 pm
by RobertGonzalez
I guess it depends on your systems needs. For me, I have always used DB sessions in conjunction with userids, email addresses/IPs and a sessionid. Generic user is either -1 or 1, all other users follow after. Each user has a unique session id that, if they choose to stay logged in, stays with them, or if they choose not to stay logged in, it refreshes the next time they log in.

Posted: Fri Nov 03, 2006 12:36 pm
by GeXus
Hmm... Ok I think i'll have to do a bit of reading.. thanks a lot!

Posted: Mon Nov 06, 2006 10:32 am
by BDKR
There is another big reason to store sessions in the DB above and beyond the issue of shared hosting environs.

Clusters!

I ran into this problem in late '01. We had multiple web servers and there was allways the possibility that the cluster or traffic managers would not
correctly route a started session* back to the same box for it's duration. There was also the fact that fail over operations needed to be as transparent
as possible. In other words, if there was a failure in the web pool or the traffic manager, the application still has access to the same session information as
the rest of the servers in the pool.

Now if you are at this level, you most likely have the money to spend on decent hardware (nevermind the fact that if you're smart enough to use open source,
you've saved a lot of money for hardware anyways! :-) ) and your database servers should be well configured and kickin' some arse right! With good index
creation and fast controllers and drives, session information stored in a db in this way wouldn't suffer much at all in terms of performance.

Another killer option (I haven't looked at this option in some time so I can't speak for it's feasibility) is a dedicated memory cache server that can sit in a
cluster and serve session information to the web or transaction servers. If it could have a fail over backup as well, it would be a very good solution for those
needing fault tolerance.


* To a load balancer, a session represents a client that has made a request to the system and that clients continued visits. What's important is how his/her
traffic is handled. Normally for the sake of PHP (or your favorite language) or application level sessions, you want to continue to route that clients traffic to
the same machine in the cluster. Normally, this is enabled by making sessions sticky.