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)



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.