Karsten,
Gilbert makes a good point here, but I don't agree with all of it....
When using a static field in a enterprise application (e.g., EJB,
servlets, web-services, enterprise spring), you should be aware that
the static field will be private to each running instance of the
application. So if you have 100 VMs running your application, each vm
will see a different copy of the static variable. In the case you
laid out below, this is acceptable.
As for the rest... I disagree. This is a complex subject so please
bear with me. In JEE a application is not really a divisible unit.
This is really due to the introduction of local interfaces in EJB
2.0. In EJB 1.x you only had remote interfaces, so a server could
theoretically deploy an application with thee EJBs to three VMs with
one EJB on each VM. In EJB 2.x, a servlet or EJB can obtain a direct
local interface to a bean and pass non-serialzable data to the bean.
Whit the introduction of JPA in EJB 3.x the application has become
even more coupled. This means that unlike EJB 1.x an application
server can not blindly distribute the EJBs in an application across
multiple VMs. To automatically distribute the EJBs in an application,
the server would have to perform some very complex static analysis to
determine which components are making direct calls to other
components. I'm not sure this is even possible, and even if it were,
I don't think you would want to do it. A distributed call is very
very slow, fault prone, and involve distributed transactions. The
last point is particularly nasty as many databases don't properly
support distributed transactions and when there are machine failures,
part of you database can be locked until the transaction log on the
failed machines are recovered. Of course, you can always manually
divide up your application into a group of applications that work
together, and in that case you will be aware of the application
boundaries and the costs of crossing them. Also, never count out IBM,
expecially when running on their most expensive hardware... they can
do magic you've never even dreamed of. Unfortunately, if you want to
run on other (less expensive) systems, you can't expect magic.
Assuming that you agree that a JEE application can not be
automatically divided up by the server, how do you achieve scaling?
Well you can divide you application by hand and/or you can use
horizontal scaling. In a horizontal scaling, you run several VMs and
each VM has the same application code running. When a client request
comes in, a request router chooses a VM and forward the request to the
VM. Since each VM is running the exact same code the router could
theoretically pick a random node but since most applications use
either client-session data or have data caches (like JPA or
Hibernate), the router typically uses a sticky load balancing rule
that forwards all requests from a single client to the same machine.
Why sticky? Well, when you have client-session data, it is becomes
very expensive to transfer the client-session state state for each
call. Even more critical to performance, a client typically accesses
the same or closely related data over their session, so if you send
them to the same machine, there will be less cache faults (this is
super critical to DB applications).
For the request router, you can use something as simple as a web load
balancer assuming the clients always use HTTP to communicate with the
server (this is my recommendation). Alternatively, there are products
like WebSphere XD Dynamic Router that can perform routing for many
different kinds of protocols (like CORBA).
Hope that helps, and wasn't too confusing
-dain
On Jun 19, 2008, at 8:19 AM, Gilbert Carl Herschberger II wrote:
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
