> > > 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.
--
greg
