geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject clustering... web/ejb/jms etc.. - a common impl
Date Thu, 11 Sep 2003 13:34:20 GMT


I've done some thinking about the chat we had about integrating web, ejb 
and jms clustering strategies. Here is a gross simplification of some of 
the stuff we covered. Hopefully you can fit JMS into the picture....

let's assume that the lb/replication strategies are combined and have 
two values: dumb and sticky.

'dumb' means the next request (web or ejb) can fall anywhere
'sticky' means it will fall wherever the last request in the same 
conversation fell

'dumb' involves synchronous replication to avoid a client request racing 
and beating a replication request to a node (although you could use 
asynchronous and cross your fingers if your LAN was fast).

'sticky' allows the luxury of asynchronous replication at a slight risk 
(in the case of failure), since we know subsequent requests will al fall 
on the same node.

'dumb' is not an environment that EJBs generally have to survive in, 
since their container is usually in charge of the client side proxy lb 
strategy. Web components, however, do need to be able to live happily in 
a dumb environment.

The fun occurs when a call needs to cross over between the two tiers:

(a) web-dumb/ejb-dumb : cross-over is local, but ejb tier must use 
synchronous replication like web-tier
(b) web-dumb/ejb-sticky: cross-over is probably remote, but ejb tier may 
use asynchronous replication
(c) web-sticky/ejb-dumb: cross-over is local -  ejb-tier gains nothing 
by synchronous replication - inefficient -it might as well be sticky
(d) web-sticky/ejb-sticky: cross-over is local - both tiers are able to 
replicate asynchrously - maximum efficiency

(a) and (b) are where the current Jetty distributable httpsession impl 
is with JB*ss, since integration between web and ejb tiers is still not 

(d) is where I want to see Geronimo go.

This of course means that in a partitioned/subclustered cluster the web 
and ejb deployments must be arranged, load-balanced and replicated 
identically so that their resources can pair up properly.

given that we have to support (IMHO) both dumb and sticky web 
environments, and the underlying replication layer will hopefully be 
reused underneath all tiers, I think it makes sense to support ejb-dumb, 
for cases where in a web-dumb environment many reads are made between 
the web tier and ejb tier for each web request. This would ensure that 
all reads are local, whilst causing no additional ejb replications.... 

There are many other issues that will impact on this, such as the 
different ways stickiness is implemented in different lbs and 
replication is implemented under different tiers, but I'm hoping that 
the overall classifications and optimisations deriving therefrom will 

So, over to you, how does JMS fit into this picture ? Are the same 
abstractions meaningful in the JMS world ? If I put a topic or queue 
into my httpsession and then wake up on a different node, will I always 
end up talking through them to a remote resource, or might these 
components be replicated locally?

and then there is JNDI :-) any JNDI experts out there ?


 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)

View raw message