How are sessions stored in memcached in non-sticky mode?

For non-sticky sessions one of the nodes is randomly elected as primary node (the nodeId is encoded in the sessionId). The logical "next" node is chosen as backup node. The session is stored in the primary node and additionally in the backup node (under a key "bak:<sessionId>"). On further requests the session is updated in both primary and backup nodes, if it wasn't modified the session is only "pinged" in memcached (to prevent expiration).

What happens in non-sticky mode when a memcached node fails?

a) Primary node fails: When the primary node is not available for a request (so that the session cannot be loaded from the primary node), it will be pulled from the backup node and the backup node will become the primary node. When the backup for the session shall be saved, the backup node will be the next node relative to the new primary one. As an example, with nodes n1, n2, n3: first n2 would be primary and n3 backup node. When n2 fails n3 will become the primary and n1 will be used as backup node.

b) Backup node fails: When the backup node fails the backup will be skipped.

Can I just use a servlet filter (& friends) instead?

(Extract from the mailing list, "memcached session integration in application layer")

Basically it's possible to use a simple servlet filter etc. for keeping sessions in memcached (or membase etc.), but there are some things to be aware of and that must be checked against your requirements.

Assuming that sticky sessions shall be used the main issue is sessionId handling: the servlet api does not allow you to specify/modify the sessionId. So you cannot encode the memcached-node of the session into the sessionId, and have to use hash based memcached node selection (be it consistent hashing or not). If a memcached fails, you can use failover handling of the memcached client lib of your choice and see if this matches your requirements. If you want to go for the servlet filter with sticky sessions, you also need to strip the jvmRoute off the sessionId to get the memcached key (in the case tomcats are configured with a jvmRoute). Otherwise, when the sessionId including the jvmRoute would be used as memcached key, the key would change on a tomcat failover as the jvmRoute is then changed to the one of the tomcat that is taking over the session.

With non-sticky sessions there are some more things to be aware of: as you want to have no sessions in tomcat stored at all you have to manager sessionIds yourselves. This includes url rewriting and cookie handling. Also you have to handle concurrent session access from different app servers (introduced by tabbed browsing or ajax etc.). Probably there are some more details to be aware of, but these are the main issues that are already covered by memcached-session-manager.

Why is it not implemented as Store for tomcats PersistentManagerBase?

The Store interface defines methods getSize(), keys() and clear() - these cannot be implemented with memcached.

Also PersistentManagerBase backups all sessions in batches (processMaxIdleBackups() is called by the background thread after active sessions have been checked for expiration). If each session shall be up to date in the store, all sessions would be sent to memcached again and again.

The memcached-session-manager instead backups a session after the request was finished, so only sessions that were (potentially) modified are sent to memcached.

How are memcached nodes selected for session backup?

When a new session is created the memcached-session-manager selects the memcached node randomly.

What's the format of the session id when using the memcached-session-manager?

The memcached node is encoded in the session id like this: <sessionId>-<node>[.<jvmRoute>] (e.g. 602F7397FBE4D9932E59A9D0E52FE178-n1 without a jvm route, with the jvm route 602F7397FBE4D9932E59A9D0E52FE178-n1.tomcat0)

Isn't memcached a cache and might drop sessions

TBD