gentlemen, not a committer here, but wanted to share some thoughts.
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
locations)
1. Requirements to be implemented by the Session.java 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 SessionManager.java 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
LazyReplicatedHashMap
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.
As you can see, access time is not relevant here, nor does the Session
API even know about clustering.
In tomcat we have separated out group communication into a separate
module, we are implementing the LazyReplicatedHashMap right now just for
this purpose.
positive thoughts, criticism and bashing are all welcome :)
Filip
