[imp] memcached sessions

[Kevin M. Myer]

Quoting Didi Rieder <adrieder at sbox.tugraz.at>:

> Could you share that code?
> How about doing the writes to all the server (which are available) 
> and doing the
> reads from one randomly picked (if the server is not available or has not the
> desired info, try the next).

I was going to put it in the bug tracker as an enhancement.  I'll try to get
that done by the end of the day today.

There are several end results you could be trying to achieve with any session
handler:

1)  Basic functionality (1 server stores all session data)
2)  A means for providing shared access to session data (2 or more 
servers store
session data, data divied up by some algorithm, with each sessionid having
affinity for one memcached server, based on the algorithm, helps address
scalability)
3)  A means for providing shared access to session data and replicating 
session
data (2 or more servers store session data, with Horde handling replication of
data across all servers, helps address scalability and high availability)

What I was working on would only implement 1 and 2, although 3 might be
possible.  The problem I see with replicating anything is you don't 
have a good
way of guaranteeing the data gets replicated.  For instance, if you are using
two servers and have one session...  You write the session info to both the
first time.  A network problem temporarily drops the connection to the second
server, so the first server is used for reads and writes exclusively.  
You need
code to detect when server 2 comes back.  And when it does come back, 
its going
to have stale session data, if any writes were done to server 1.  So if you do
a read to server 2, you're going to get different results than if you read
server 1.  So I think doing replication might be tricky, because there's no
good way to determine the state of the information across multiple 
servers. Now if you had a way to pool memcached, so that it handled 
replications itself
(say by specifiying peers to the memcached process at startup, and if a change
was received, that information was passed to all peers by the memcached
process), that might be interesting, but it would also add complexity and the
overhead of trying to maintain consistency might kill the speed.  Always
tradeoffs somewhere..

A different set of issues arises with simple shared access to session data,
namely that if you lose a server, the portion of your users who have session
data stored there are suddenly going to be orphaned.  I believe Liam at UMich
had proposed a sessionhandler with a fallback mechanism, should the preferred
mechanism go away for whatever reason.  Maybe that could get 
implemented in the
general SessionHandler class - try a driver-based handler, if a connectivity
failure is detected there, fall back to something that should always work.

And there's probably a bunch of cases or scenarios I've overlooked.

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org