About Tomcat BackupManager

Tomcat BackupManager is another cluster session manager. It is also sibling class with DeltaManager.

Some important features of BackupManager

• It is activated by declaring <Manager className=”org.apache.catalina.ha.session.BackupManager“> inside <Cluster> tag
• When an instance create a sesion, that instance becomes the session’s primary node. Another node becomes backup node and all the other node become proxy node
• A session data is copied to only one backup node. Therefore the cluster can tolerate one instance’s failure
• Backup node is chosen in round robin
• Proxy node has session id and primary, backup node’s address. If a proxy node get a request for the session, it sends requests to the primary node and provides the session data. Therefore, client can access every session from every node (Location transparency)
• BackupManager overrides ManagerBase sessions member attribute. Therefore, ManagerBase’s logic is applied to BackupManager’s sessions object
• ManagerBase’s sessions attribute is ConcurrentHashMap, but BackupManager’s sessions attribute is LazyReplicatedMap which is also the implementation of Map.
• LazyReplicatedMap , as the name implies, manages local map and replicates data among cluster afterward. Most replication logic is located in this class (or parent class)

How session replication works

Session creation

When a session is created, the following call sequence happens.

HttpServletRequest.getSession() -> ManagerBase.add() -> BackupManager.sessions.put() -> LazyReplicatedMap.put()

Inside LazyReplicatedMap.put() (to be exact, AbstractReplicatedMap.put()) 1) adds to local map 2) sends a copy to a backup node

Broadcasting to proxy nodes happens when the request is finished at ReplicationValve (ReplicationValve must be declared inside <Cluster>)

Session update

When a session is updated, replication to backup and proxy nodes happens at ReplicationValve

ReplicationValve.invoke() -> ReplicationValve.sendReplicationMessage() -> ReplicationValve.sendMessage() -> ReplicationValve.send() -> BackupManager.requestCompleted() -> AbstractReplicatedMap.replicate() (repliction to backup and proxy node)

Session delete

When a session is deleted, replication happens at BackupManager

HttpSession.invalidate() -> ManagerBase.remove() -> BackupManager.sessions.remove() -> AbstractReplicatedMap.remove()

Implication from the inner working analysis

• Session delete is replicated in real time, but creation and update is done when servlet processing is finished. Therefore concurrent access to a session can cause integrity issue
• BackupManager uses less memory and network bandwidth than DeltaManager. But total network call count is equal
• For optimal performance, sticky session should be used. Sticky session routes a http request to primary node (mod_jk or mod_proxy supports it)