geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Date Mon, 06 Mar 2006 09:12:16 GMT
Filip Hanik - Dev Lists wrote:
> 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.


I think the API should be thought of in two parts:
  a session API
  a session policy API.

The bits about location etc. are all in the session policy API.

The mechanism you describe below for replication, is just one way
to handle session state in a cluster.

You may have distributed state without replication
You may have a central stor of state (eg database) with it's
own fault tolerance and clustering capabilites.

Also, good session management needs to take place proactively - 
not just when the session API is being called.   Nodes need to be 
shutdown, load might need to be rebalanced.   So having an
API that does know about session location and has the ability
to move them will allow the development of plugable and
configurable policies that manage the way state moves
around a cluster.

So I hope that the implementation that you describe below could
become one of the implementations of the G session API.   Then
when a geronimo cluster wishes to shutdown a node, it can use this
API to tell your LazyReplicatedHashMap to move sessions off a node
(or to find a different backup for sessions on other nodes).
This could be done without writing LazyReplicatedHashMap specific


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

View raw message