On 7 May 2000, Greg Stark wrote:
>
> > > > Further, what are the standard ways to load balance a session-tracking
> > > > app across multiple servers when the sessions are stored in memory and a
> > > > given user has to be consistently sent back to the same machine? Can
> > > > round-robin DNS be counted on to send people back to the same server
> > > > over the life of a given session?
> >
> > On my sites I use a central database for storing the session objects, and
> > all of the https servers access this central resource. Obviously if it
> > goes down, everything is toast, but the same can be said of the database
> > that stores all of the customer information, etc.
>
> I've written some pretty heavy database driven sites that do some pretty
> complicated things and I've *never* found it really necessary to have a server
> side session database. In theory you might find it convenient to cache big
> complex data structures for the session, but in practice most people use it
> for storing things like usernames and shopping cart contents.
>
> My suggestion is to put the state information in the cookie directly. Include
> a crypto hash (with a secret) to sign the cookie and be done with it. If the
> information is sensitive then encrypt the whole thing.
>
> Then your sessions are completely stateless, they can migrate between mod_perl
> processes, even across servers. They can even survive server reboots. And They
> don't require additional infrastructure to store the database of sessions.
>
> I keep meaning to write this up as an Apache:: module, but it's pretty trivial
> to cons up an application-specific version. The only thing this doesn't
> provide is a way to deal with large data structures. But generally if the
> application is big enough to need such data structures you have a real
> database from which you can reconstruct the data on each request, just store
> the state information in the cookie.
Your post does a significant amount of hand waving regarding people's
requirements for their websites. I try to keep an open mind when giving
advice and realize that people all have different needs. That's why I
prefixed my advice with "On my sites..."
On my sites, I use the session as a general purpose data sink. I find
that I can significantly improve user experience by keeping things in the
session related to the user-site interaction. These session object
contain way more information than could be stuffed into a cookie, even if
I assumed that all of my users had cookies turned on. Note also that
sending a large cookie can significantly increase the size of the
request. That's bad for modem users.
Your site may be different. In fact, it had better be! :)
-jwb
