I think the normal approach is some variation of #1. keep the sessions
in a common place.
I use memcached as my primary session store, with a backup copy stored
on a common drbd replicated filesystem partition that is mounted on
all my app servers. This means that if it ever can't get the session
from memcache (ie the cache was flushed), it will retrieve it from the
filesystem (slightly slower), and if even that fails, i can re-create
a basic session (authentication/user info only) from an encrypted
cookie from the client.
This allows the client to always get a working session regardless of
which app server they get connected to. It also means that i can use
leastconns load balancing which is exactly what i want.
--
Jehiah
hopefully my approach to sessions is generic enough that you can write
the code necessary to change how twisted sessions are handled. I can't
give any tips on that though, and it's probably a question better
suited to a twisted specific list more than this load balancing list.
--
Jehiah