Session replication / clustering / failover with Tomcat (Part 1 - Overview)

This is my first post of a series about Tomcat and clustering.
In this post i will explain some different replication mechanism.


NOTE: A common drawback of replication, like it's defined in the specs, is that only HttpSession#setAttribute(...) triggers replication.
This means that if you store a container object in the session and if you change a variable inside the object, you must HttpSession#setAttribute(...) again to replicate the modified object again.
Many frameworks implements a simple workaround for it - i will write about it another post.

All to all replication / DeltaManager 

With this mode, Tomcat just replicates the session to all registered nodes.

Pro:

• No single point of failure at software level
• Every node holds all sessions
• In theory, all other nodes can be turned off
• No extra software is needed
• Synchronous or Asynchronous replication
• Open Source
• Enterprise-Support available

Contra:

• High memory usage and network traffic because all nodes holds all sessions
• Objects which are stored in the session must be triggered manually to replicate again if a property has been changed
• Slower session serialization

Primary/Secondary Replication (Buddy Replication) / BackupManager

The sessions will be replicated to the next neighbor. If one Tomcat is not available anymore, the neighbor still holds the sessions.

 Pro:

• No single point of failure at software level
• Lower memory usage and network traffic because the session is not stored on all nodes
• No extra software is needed
• Synchronous or Asynchronous replication
• Open Source
• Enterprise-Support available

 Contra:

• Not quite as battle tested as the All-to-all replication (see Tomcat documentation)
• Objects which are stored in the session must be triggered manually to replicate again if a property has been change
• Slower session serialization

Memcached-session-manager

Each Tomcat replicates all sessions to N (multiple) Memcached nodes.
If a session is not available on the local Tomcat, the memcached-session-manager tries to lookup the session from the Memcached nodes.

 Pro:

• No single point of failure at software level
• More scalability
• Session will be replicated to N “Memcached” nodes – The sessions are still available if all webservers are down
• Automatically handles “Memcached” nodes failover
• Sticky mode: Lower memory usage because every node holds only the current used sessions
• Non-Sticky mode: Lowest memory usage because Tomcat does not hold the sessions anymore. Session will be received from memcached for each request
• MSM will automatically trigger replication if a property in a session stored object has been changed
• Faster session serialization – Changeable mechanism
• Synchronous or Asynchronous replication
• Open Source
• Enterprise-Support available for Tomcat

 Contra:

• Extra software needed (“Memcached” plugin and nodes)
• Cannot switch to another Java Webserver which does not automatically check changed values in the session - but only if the used framework has no implemented workaround
• AFAIK no Enterprise-Support available for the Memcached plugin but Martin Grotzke is very active on the mailing list