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
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>)
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)
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)