On Thu, 16 Dec 1999, Simon Rosenthal wrote:
> a) If your site runs on multiple servers, do you attempt to cache session
> state records on the web server for any length of time after they are
> retrieved from the DBMS ? and if so, how do you handle cache consistency
> across all your servers - (we have rather blind load balancing hardware in
> front of our server farm with no way of implementing any kind of server
> affinity that I am aware of)
Apache::Session::DBI doesn't try to do this, but you could add it yourself
using some kind of shared memory approach, and implementing it as a
write-through cache. However, you will not be able to cache sessions at
all if you can't ensure that users will return to the same machine every
time. You must have server affinity.
> b) Does anyone have redundant database servers ? If so ... are there any
> implementation gotchas ? and if you have a single server, how does session
> management work when it goes down ? (I'm pretty happy with the hardware -
> Suns - which we have, but a disk can go at any time....)
It's pretty hard to mirror a database in real time, and MySQL doesn't have
any built in stuff to help. Most people run with a single-point of
failure and use redundancy to ensure they can get back up quickly.
Seamless failover of session data with 0 data loss would require writing
it to multiple places on every save, which would hurt your performance.
> c) This is more of a mysql question.... When do people consider a session
> to have expired ? and what is the best strategy for deleting expired
> sessions from a database, especially given that mysql's table based locking
> seems to leave a bit to be desired if you're trying to mix update
> operations with a big SELECT/DELETE to purge expired sessions ?
Doesn't MySQL support qeued statements that wait for an opportunity to
slip in without holding things up?
- Perrin
