storing sessions in DB

Questions about the MySQL, PostgreSQL, and most other databases, as well as using it with PHP can be asked here.

Moderator: General Moderators

Post Reply
GeXus
Forum Regular
Posts: 631
Joined: Sat Mar 11, 2006 8:59 am

storing sessions in DB

Post 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..
User avatar
kaszu
Forum Regular
Posts: 749
Joined: Wed Jul 19, 2006 7:29 am

Post 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
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
GeXus
Forum Regular
Posts: 631
Joined: Sat Mar 11, 2006 8:59 am

Post 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?
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
GeXus
Forum Regular
Posts: 631
Joined: Sat Mar 11, 2006 8:59 am

Post 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?
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
GeXus
Forum Regular
Posts: 631
Joined: Sat Mar 11, 2006 8:59 am

Post by GeXus »

Hmm... Ok I think i'll have to do a bit of reading.. thanks a lot!
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post 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.
Post Reply