On Friday, 18 March 2011 at 20:18, tedd wrote: At 8:03 PM +0000 3/18/11, Stuart Dallas wrote: > > 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: > > When looking at: > > http://docstore.mik.ua/orelly/webprog/webdb/appd_03.htm > > I can see that sessions are tied to a db and if the servers have > access to a common db, then sessions can travel between servers. I too have a MySQL implementation of sessions: http://stut.net/2008/07/20/mysql-sessions/ > When looking at: > > http://stut.net/2008/07/26/sessionless-sessions-2/ > > I see that you've tied your "session" to an encrypted cookie and of > course that cookie would travel between servers because it is tied > to the user's computer. > > In both cases, the user's activity is carried across different > servers. But in your solution, I would say the data is "limited" > because you are using a cookie, whereas, using a session can carry > more data. On the other hand, your solution causes less burden on the > server than using a database. > > Is that it? I'm not sure where the confusion is here, so let's start with the basics - I apologise if this is too basic. A cookie is data that is sent back and forth between the browser and server in HTTP headers. So it is slightly inaccurate to say that the session data "travels between servers". The session data is in the cookie which is part of the request. So it gets sent to the browser in response to a request by server A. The browser then sends that data with the next request that ends up at server B. There is no communication between the servers. With a DB-based session a cookie is usually still involved, but that cookie only stores an ID that identifies the session. For a DB-based session that would normally be the primary key in the session table. In both cases the session is "tied" to the cookie; the difference lies in where the actual session data is stored. I hope that makes it clearer. Yes, when storing the session data in a cookie there is limited space available, whereas you could say storage in a database is practically unlimited, but in return for limiting your session data and storing it in a cookie you reduce your contribution to the load on the DB. -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
