tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilbert Carl Herschberger II <>
Subject Re: AW: Store data in SessionContext
Date Thu, 19 Jun 2008 15:19:12 GMT
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.


At 02:12 PM 6/18/2008, you wrote:
>On Jun 18, 2008, at 1:19 AM, <> 
>< > 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.

View raw message