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
