Does any implementation of EJB container automatically distribute
beans? Yes, IBM WebSphere.
IBM WebSphere comes bundled with IBM i Series and z Series. For
example, it provides support for distributing EJBs across a farm of
containers, with a load-balancing and fail-over monitor. With an EJB
container farm, an incoming request is dispatched to any container. A
transaction is distributed, too.
An EJB container farm is for enterprise-level runtime performance.
Load-balancing enables the dispatcher to forward an incoming request
to an "idle" EJB container. Fail-over enables the dispatcher to
detect when an EJB container is no longer responding.
As we know, a static field is unique within a classloader and does
not participate in the serialization mechanism. Therefore, a static
field does not work across passivate/activate. Any resource that must
be "static" cannot be distributed. You can, and should, design with
these limitations in mind.
Static fields in an EJB are not "allowed" according to the
specification. This rule is not enforced with an error message.
Rather, it is a serious warning that static fields do not work as
some might expect in an EJB container farm.
Thanks,
At 02:12 PM 6/18/2008, you wrote:
On Jun 18, 2008, at 1:19 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED] > wrote:
Are static fields also allowed in interceptors like I want to do it?
According to the spec they are not allowed, but it is an
unenforceable and in my opinion a stupid restriction. To my
knowledge no vendor actually stops you from using static
fields. If you really really
want to be spec compliant, put the actual field in another class.
This is legal since EJBs are allowed to use other Java classes.
So it is always the case that during the execution of a bean chain
each bean stays on the same server instance? Or can it be imagined
that some mechanism distributes beans to other VMs where the static
information is missing?
In the early days, of EJB there were lots of ideas about how one could
build an EJB server, which led to the restrictions section in the EJB
spec. One or the more unique designs came from Enhydra, which
envisioned a single EJB server running over a set of vms. The idea
was this would make your applications scale effortlessly. I don't
believe they ever finished building the system, and if they ever did,
I doubt it would be very efficient given the cost of an rpc vs a local
call. In the end the industry settled down to a single vm design and
scaleability is achieved horizontally with homogeneous servers. I
wish the spec committee would simply drop all of the restrictions and
adopt the restrictions of Servlets.
Anyway, I am not aware of any EJB implementations that automatically
start distributing beans. A call to bean in a remote vm has such
different behavior compared to local bean, that EJB server can't
automatically start distributing beans remote VMs. When you have a
truly remote call in an application, you typically need to design the
application with this in mind, since remote calls can fail for random
reasons, and local calls really only fail for a small set of known
problems. As a programmer you are normally aware which beans are
truely Remote because they have special configurations to tell the
server where the bean is located, security requirements, and other rpc
protocol information.
-dain
