tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject [feedback request] session replication
Date Fri, 03 Mar 2006 16:44:21 GMT
I wrote together a little idea (also emailed to geronimo-dev for 
feedback) on how the next generation of session replication should be done.
Today's replication is an all-to-all replication, and within that realm, 
its pretty poor. It creates way to much network traffic as each request 
results in X number of network transmits (where X is the number of nodes 
in the cluster/domain).

The suggested solution offers two advantages:
1. Each request with a dirty session should only result in 1 network 
send (unless session create, session delete, or failover)
2. The session Manager (StandardManager,DeltaManager,etc) should not 
have to know about replication, the DeltaManager today is too 
complicated and too involved in the replication logic.

I propose a very simple, yet very efficient replication mechanism, that 
is so straight forward that with a simple extension of the 
StandardSession (if not even built in) you can have session replication. 
It will even support future efforts for replication when we can have AOP 
monitor the sessions itself for data that has changed without 
setAttribute/removeAttribute, and the implementation wouldn't change much.

in my opinion, the Session API should not have to know about clustering 
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.

the solution that we plan to implement for Tomcat is fairly straight 
forward. Let me see if I can give an idea of how the API shouldn't need 
to worry, its a little lengthy, but it shows that the Session and the 
SessionManager need to know zero about clustering or session locations. 
(this is only one solution, and other solutions should demonstrate the 
same point, SessionAPI need to know nothing about clustering or session 

1. Requirements to be implemented by the API
  bool isDirty - (has the session changed in this request)
  bool isDiffable - is the session able provide a diff
  byte[] getSessionData() - returns the whole session
  byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
  void setSessionDiff(byte[] diff) - optional, see isDiffable, apply 
changes from another node

2. Requirements to be implemented by the API
  void setSessionMap(HashMap map) - makes the map implementation pluggable

3. And the key to this, is that we will have an implementation of a 
  The key object in this map is the session Id.
  The map entry object is an object that looks like this
  ReplicatedEntry {
     string id;//sessionid
     bool isPrimary; //does this node hold the data
     bool isBackup; //does this node hold backup data
     Session session; //not null values for primary and backup nodes
     Member primary; //information about the primary node
     Member backup; //information about the backup node

  The LazyReplicatedHashMap overrides get(key) and put(id,session)

So all the nodes will have the a sessionId,ReplicatedEntry combinations 
in their session map. But only two nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB 
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new one, 
and do a publish to the entire cluster of the locations.

As you can see, all-to-all communications only happens when a Session is 
(created|destroyed|failover). Other than that it is primary-to-backup 
communication only, and this can be in terms of diffs or entire sessions 
using the isDirty or getDiff. This is triggered either by an interceptor 
at the end of each request or by a batch process for less network jitter 
but less accuracy (but adequate) for fail over.

What makes this possible will be that Tribes will have true state 
replication and other true RPC calls into the cluster.

positive thoughts, criticism and bashing are all welcome :)
(remember that I work with the KISS principle)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message