-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Santiago Gala
Sent: Thursday, June 01, 2000 1:40 AM
To: John Yu
Cc: Philip Wilson; [EMAIL PROTECTED]; Wayne Stidolph
Subject: Re: Questions about the EJB paradigm
John Yu wrote:
> Hi Philip,
>
> > No, you just don't let the fine-grained objects talk in a fine-grained
way
> > to the client. As far as the client is concerned, you wrap them up in a
> > coarse-grained Session Bean. The fine-grained objects interact with
each
> > other in the server-side code; this is presumably how MSF works too,
> > otherwise it would have the same problems with inefficient fine-grained
> > interactions over a network.
>
> Yup, I understand that if my fine-grained Entity Beans are co-located with
my
> coarse-grained Session Beans and I let the clients talk to only the
Session
> Beans, it should eliminate most of the network traffic overhead.
>
> But this creates a problem related to the first question I asked in my
first
> post. As soon as I require *massive* scalability, I may want to distribute
the
> load across multiple machines. I will end up having the Session Beans
running on
> machine A and the fine-grained Entity Beans running on machine B. The
remote
> call overhead comes back.
>
> Besides, when the namespace-based load balancing becomes available (ie.
having
> multiple objects running on different machines bound under the same name),
I can
> no longer assume the Session Beans and Entity Beans are co-located.
>
> (Wayne Stidolph told me namespace-based load balancing would be available
on
> Enhydra Enterprise.)
>
> Hmm, it seems one solution is to have the namespace-based load balancing
engine
> smart enough to make sure the fine-grained entity beans run with the
> coarse-grained session beans on the same VM. (Is it possible, Wayne?)
>
> After these discussions, it seems to me while the issues I raised can be
> overcome, these issues are currently not addressed by the EJB
architecture.
[snip]
Seeking co-location is a problem with no generic solution (what policy do
you want enforced when you fire up two coarse-grained session beans on
different VMs then they both use the same fine-grained entity bean?) And it
isn't always clear that you want co-location; it depends on the impacts
(costs) ... for example, maybe co-location puts too great a load on the one
server in terms of available database connections, and having many network
connects is OK by you, you *want* to trade of latency for
database-connection license fee reduction.
The answers never seem to be perfect.... when you get to massive scale for
an application, it becomes worthwhile to analyze your data-interaction
patterns and partition your data and behavior so that they normally reside
close together, just as it is worthwhile to partition your data to make sure
you only lock up or transport the data you're actually using.
I think that what the server can do is to provide some run-time
optimizations that probably won't *hurt* your application - like
namespace-based servant selection. So, first we will get load-distribution
through the namespace mechanism, and we will try for session affinity as we
have in Enhydra today (once you start using a particular EJB Server, we will
check for your EJBs first on *that* server, that sort of thought). With
reasonable scales and deployment practices, this will work pretty well. (And
we'll ensure the servent-selector is easy to replace on a per-Context basis,
so you can essentially "tune" this somewhat to you application, even having
different selection functions for different resources according to the way
you lay out the namespace.)
The next step is chancy ... session mobility and/or dynamic redeployment.
(Like a database engine that optimizes table structures as queries come
through.) Some of this (at least the session mobility) could come with the
enhanced clustering and failover capabilities (being thought out now - Simon
Tuffs is on it - but not planned for code in the next release). Highly
dynamic redeployment is lots and lots trickier ... where we have malleable
servers scattered about, and if you need an entity bean not deployed on the
server with your session bean, maybe we redeploy that EB to your local
server the 100th time you look it up in the namespace. Raises many ugly
issues...
As to these problems being not addressed by the EJB spec, I think that is
intentional: the spec is philosophically keen on the idea of location
transparency for each bean, and on the idea of different vendors implmenting
different quality of service for different scales. In the very-nice Open
Source case, you get to affect that QoS decision, or even override the
implementation we provide.
Wayne Stidolph
Lutris Technologies
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
