Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44089789.9080504@hanik.com>
Date: Fri, 03 Mar 2006 13:22:49 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Session Policy was: heads up: initial contribution of a client
 API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
References: <1F5F68F5-2E35-4AAF-B90B-072081D34FE7@gmail.com>
 <44042DE9.2080203@mortbay.com>
 <F10E5C28-9354-4C62-84B8-2FA718F27720@iq80.com>
 <4406A4DE.2070603@mortbay.com>
 <E4F739BA-93E1-4C51-AF9A-6286CFCB2A4B@iq80.com>
In-Reply-To: <E4F739BA-93E1-4C51-AF9A-6286CFCB2A4B@iq80.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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