tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject AW: AW: Store data in SessionContext
Date Thu, 19 Jun 2008 09:31:31 GMT
Thanks, a lot.


> -----Urspr√ľngliche Nachricht-----
> Von: Dain Sundstrom [] 
> Gesendet: Mittwoch, 18. Juni 2008 20:13
> An:
> Betreff: Re: AW: Store data in SessionContext
> 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.
> -dain

View raw message