tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: AW: Store data in SessionContext
Date Wed, 18 Jun 2008 18:12:58 GMT
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