On Friday, 18 March 2011 at 19:56, tedd wrote: At 7:26 PM +0000 3/18/11, Stuart Dallas wrote: > > On Friday, 18 March 2011 at 19:14, tedd wrote: > > At 3:53 PM +0000 3/18/11, Stuart Dallas wrote: > > > > The cookies I use to replace sessions are session-based cookies and > > > > last no longer than a traditional PHP session. The key is to provide > > > > a lightweight method of ensuring that whichever server processes the > > > > request has access to the session data. > > > > > > > > > > > > -Stuart > > > > > > Stuart: > > > > > > Ahhhh, I think I see. > > > > > > This is a means to keep a user's session current across several > > > servers. It basically creates a "session-like" communication between > > > servers so that a load balancer can direct traffic accordingly > > > without losing the user's state. > > > > > > Is that it? > > > > I wouldn't call it communication, but that's the gist, yes. > > > > -Stuart > > Are the server's sharing a common database?
Usually, yes, but the point is to remove the need to make a database connection unless it's absolutely necessary. If every request you're getting will hit the database anyway I see no issue with using that same database to store session data. Most of the sites I work with have a caching layer which enables the bulk of the pages (i.e. those where the content is not user-specific) to be built without accessing the database. In such situations you'll usually have some small parts of the page that are user-specific, such as the fact the user is logged in. For that you will probably want their name and/or username and their user ID. You may also want their email address to pre-fill forms, etc. I store that stuff in an encrypted cookie so I can still customise small parts of the page without hitting the DB. Hope that makes sense. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
