[imp] concurrent session support

[Gary Windham]

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

> Quoting Kevin Konowalec <kevin at ualberta.net>:
>
>>
>> Has anyone successfully implemented a multi-server horde setup using
>> mysql sessions?  I've just upgraded to the latest version of imp,
>> which I was hoping would solve the "requested message not found"
>> problem that was attributed to concurrent sessions with sql backends
>> that may not support locking.  Unfortunately it doesn't.  Not being a
>> mySQL DBA I have no idea how to check if my installation does or
>> doesn't support locking.  All I know is that I need to fix this
>> problem because a LOT of users are complaining about it.  Can anyone
>> share how they solved/avoided this problem?
>>
>> I know some places use memcached as their common session backend.
>> Can anyone share any insight on how they set that up and how well it
>> works in a multi-front-end environment?
>
> We have a multi-sever installation here (cvs HEAD) and experience the
> same problems.
> We just recently switched from mysql-session-backend to the
> memcached-backend but the "requested message not found" is still
> present. Besides of that the memcached-backend works without problems.
> Our multiserver installation uses also sticky connection, so that a
> client gets always connected to the same server within a
> browser-session.
> I would also be very much interested in a solution.

We also have a multi-server installation, using memcached as the session
handler.  We are using a load balancing device w/ "sticky session" support in
order to pin a browser session to a particular server.

In order to get around the "requested message not found" issue (which is due
to no serialization of concurrent session access) we hacked-up the memcached
session driver to use a "lock file" (with the same flock() behavior as the
standard PHP files-based session driver), which serves to single-thread
access to the memcached session.

The upside of this is that if a machine in the cluster goes down, users'
sessions continue transparently on other nodes.  The downside is that if the
memcached server croaks, all sessions are lost (we run our memcached server
in a heartbeat cluster, so it is immediately restarted--but all users still
have to re-login).  Also, this only works with sticky sessions, as the file
locking only restricts intra-server concurrent session access (it doesn't
work reliably across NFS).

I would be happy to share the code with anyone interested....shoot me an email
off-list.

--Gary

--
Gary Windham
Systems Programmer, Principal
The University of Arizona, CCIT