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.
**********************************/
