All to all replication / DeltaManager

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

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

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

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

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

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

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.With this mode, Tomcat just replicates the session to all registered nodes.Pro:Contra:The sessions will be replicated to the next neighbor. If one Tomcat is not available anymore, the neighbor still holds the sessions.Pro:Contra: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:Contra: