javakaffee

I just started my first project on google code with the source code hosted in github: the memcached session manager.

– At first I must say - creating new projects on google code or github feels completely different compared to some years ago when project were hosted on sourceforge.net. Remembering this feels somehow like stoneage :) –

So, back to the memcached session manager…

What problem does the memcached-session-manager solve?

Imagine you have a web application with sticky sessions running on tomcat and want to have some kind of session failover. You want to have a scalable solution for that – just add more servers to handle an increasing number of sessions. This can be handled by sessions that are stored for backup in memcached nodes: If a tomcat dies all other tomcats will take over the work of the lazy/dead one and fetch the sessions from the appropriate memcached node(s) and serve this session from thereon.

How does it work?

The MemcachedSessionManager installed in a tomcat holds all sessions locally in the own jvm, just like the StandardManager does it as well.

Additionally, after a request was finished, the session (only if existing) is additionally sent to a memcached node for backup.

When the next request for this session has to be served, the session is locally available and can be used, after this second request is finished the session again goes to the memcached node.

Now imagine the tomcat dies.

The next request will be routed to another tomcat. This tomcat (in more detail the memcached session manager) is asked for a session he does not know. He will now lookup the session in the memcached node (based on an id that was appended to the sessionId when the session was created). He will fetch the session from memcached and store the session locally in its own jvm - he is responsible for that session from now on. After the tomcat served this request of course he also sends the session to the memcached node.

That’s all.

What more?

Also memcached node failover is implemented: if a memcached node is not available anymore the session will be moved to anoder node - also the sessionId will be modified and a new JSESSIONID cookie will be sent to the browser.
How does the sessionId look like?

The memcached session manager knows a list of memcached nodes (e.g. as localhost:11211 localhost:11212 that he references by indes. This index is appended to the sessionId, so the sessionId might be 602F7397FBE4D9932E59A9D0E52FE178.0.

What’s planned?

• Update list of memcached nodes via JMX
• Automated integration testing of all this (start memcached servers, start tomcats, make requests + create sessions, simulate tomcat failure etc.)

Perhaps this is useful for other people as well - enjoy it and give feedback! :)