Thanks, a lot. WBR, Karsten
> -----Ursprüngliche Nachricht----- > Von: Dain Sundstrom [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 18. Juni 2008 20:13 > An: [email protected] > Betreff: Re: AW: Store data in SessionContext > > 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 >
