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: <43DDE540.5050705@coredevelopers.net>
Date: Mon, 30 Jan 2006 10:06:56 +0000
From: Jules Gosnell <jules@coredevelopers.net>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: dev@geronimo.apache.org,  wadi-dev@incubator.apache.org,
 dev@wadi.codehaus.org
Subject: Clustering - WADI/ActiveSpace Synergy...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


My understanding of ActiveSpace is that it supports two state clustering 
abstractions :

- Cache - a Map-like API
- Space - a JavaSpace like paradigm (also allowing a pub/sub model)

WADI provides a third model, I have been trying unsuccessfully, to think 
of a nice name for it - lets call it a 'Meet' (in WADI it is currently 
called a 'Contextualiser').

You give a Meet a Session ID and a self-contained Invocation 
(HttpReq/Res pair, OpenEJB Invocation, etc...). It guarantees that, if 
the Session is known, the Invocation will be run against it, but, 
importantly, it does not say anything about where in the cluster this 
may occur. i.e. Invocation and Session will 'meet' somewhere in the 
cluster. It is important to maintain location independance as this 
enables the cluster to decide for itself the most efficient way to get 
this done and opens up opportunities for state-balancing and intelligent 
invocation routing etc (customer prioritising etc...).

Perhaps this model can be implemented on top of a CacheCommand? If so, 
we don't really need the 'Meet' - it just becomes syntactic sugar.

So, it should be fairly simple to implement a LocalMeet, i.e. a Meet 
where the Invocation is always run locally, by throwing the Meet API 
around an ActiveSpace Cache - as this will always migrate the Session to 
the Invocation.

This would be worthwhile, because we would be able to plug e.g. an AS 
ClusteredCache straight into Jetty/Tomcat/OpenEJB, using WADI as the 
integration. We will also get Transactions, via AS' TransactionalCache.

WADI's current implementation of a Meet implements a form of partitioned 
cache. The benefit of this is that a cluster can support more sessions 
than can be held on any single node (a constraint that applies if every 
node holds a copy of every session). The downside is that this approach 
is much more complex.

By implementing a LocalMeet on top of AS Cache impls, we can quickly 
provide a simpler impl than WADI's default, which is able to immediately 
fill demand in smaller sized clusters, whilst we continue to work on the 
large-scale solution in WADI.

The final difference between WADI and and AS (impl) is that WADI locks 
pessimistically, whereas, my understanding is that, existing AS impls 
lock optimistically (I understand that the AS API does not mandate any 
particular locking approach, but I am talking about impls available to 
us today). Provided that you can guarantee that all concurrent 
invocations will always land on the same node, an optimistic approach 
should be enough. In the web world, certain higher end http load 
blancers can provide this guarantee and in the EJB world, we can 
certainly do the same. This means that an AS based solution, integrated 
with various containers via WADI code, will, in many cases, be sufficient.

Finally, as discussed with James on numerous occasions, we should look 
at how WADI's pessimistic locking and PartitionManager might be 
componentised so that they can be plugged into AS to provide Cache and 
Space users, who are not interested in location-independance, with a 
pessimistic approach and/or a partitioned clustering substrate...


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