Clustering - client state in web, ejb and POJO tiers...

[Jules Gosnell <ju...@coredevelopers.net>]

I've been giving more thought to how we should unify our approach to the 
management of clustered state in different Geronimo tiers.

I've already talked about a common approach to the management of 
HttpSessions in both Jetty and Tomcat, as well as SFSBs in OpenEJB.

I've mentioned the abstraction of an ApplicationSession - a component 
that can hold the sessions associated with a single user:application 
relationship, so that they can remain colocated after e.g. being 
evacuated from a node that is being shutdown.

After further thought, I'm beginning to crystallise some sort of design 
around this in my head - so I thought that I would put it out here for 
everyone to kick around.

Here are the requirements that have lead to the latest reiteration :

1. We need a way of relating client state, held in disparate tiers, back 
to a common point - e.g. in a simple web/ejb app that has an HttpSession 
and an SFSB (created by the webapp to do work on behalf of the webapps 
client), in many cases, the colocation of the two sessions is important 
for the performance of the application. If we just plug together 
isolated containers (AFAIK) there is no simple way to relate the two 
sessions to each other. If the node on which they are held is shut down 
and, in order to maintain their availability, they are evacuated to 
another node, there will be no guarantee that both will end up on the 
same node. This lead to my idea of an ApplicationSession component, in 
which the web-session and any number of SFSBs could be held.

2. Apparently, the Portlet TCK imposes a requirement for relating client 
state held by the same user in DIFFERENT applications, back to the same 
point. I've had long conversations with David Jencks about this and it 
appears that the only way to pass the testsuite is to relate different 
portlet session instances held in different portlet apps, but associated 
with the same user (session id) to each other. If one session is 
invalidated, then all sessions are invalidated. This has got me thinking 
in terms not of an Application Session but more of a Server or even 
Cluster-wide Session.

Futher benefits derive from keeping tabs on who owns what in each tier 
as it will help spot orphanned objects and allow us to do things like 
ensure that if a web session is paged out all associated SFSBs get paged 
out at the same time. There is no point in keeping them active if no-one 
can get to them etc...

Finally, we have to assume that developers will build their own custom 
services with their own POJOs and that these will come up against the 
same problems that the standard containers face and will also have to 
integrate with them. So we can see that whatever solution that we come 
up with will have to make allowances for this sort of approach as well.


In terms of colocation, it should not be difficult to implement the 
different requirements above. I can envisage a ColocationPolicy 
interface with ColocateByUser, ColocateByApplication and 
IndividualLocation policies....
Each one would provide a Session Factory and a means for each tier to 
put and get their session to/from the User/Application/Individual 
Session object in which it was stored. This larger object would be the 
one put into the e.g. Distributed Cache that managed Cluster state and 
its granularity would control whether related sessions were therefore 
colocated. Getting this all up and running would probably involve the 
cooperation of all containers in sharing a single session id generator 
and namespace.

The problem arises when we want to express the realtionship between 
objects without colocating them. e.g. in a heterogeneous cluster. 
Whether we need to allow for this at this stage I am not sure. I'm still 
thinking about this and would welcome input from anyone, especially if 
they can provide more usecases, or perhaps constrain the ones we have 
already, or just come up with an elegant way of expressing all of this 
for non-colocated sessions...

cheers,


Jules



-- 
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/