geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Date Fri, 03 Mar 2006 15:00:44 GMT
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


  

Mime
View raw message