hmmmm ... I understand the case where, for instance, the field holds
something that uses system resources like an open file-based stream.
However, in this case the goal is to eliminate the repeated lookups for home
interfaces. There would be little savings if we get the home interfaces in
the ejbCreate and nulled them in ejbRemove, but the interesting question for
us is 'will the field still be valid, and if not how can one tell so it can
be made valid again?' .. so we can safely lazy initialize those fields.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Boehle
> Sent: Wednesday, December 13, 2000 4:28 PM
> To: Orion-Interest
> Subject: RE: Stateless session beans reuse
>
>
> My understanding is that the fields will not be set to null. Instance
> variables are useful in stateless session beans to hold references to
> "global" objects/resources that are used over and over again. You can
> allocate/release the variables in ejb[Post]Create()/ejbRemove(). Please,
> someone else tell me if I am wrong! :)
>
> Jason Boehle
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: John D'Ausilio [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 13, 2000 1:42 PM
> To: Orion-Interest
> Subject: Stateless session beans reuse
>
>
> Stateless session beans are clearly allowed to have instance variables
> (fields). A client of a stateless session bean cannot assume that
> he has the
> same bean instance for each method call.
>
> Assume we have a stateless session bean, which holds some fields storing
> various home interfaces. Gary (my co-worker) and I disagree in
> interpreting
> the EJB spec on what happens to those fields between method calls,
> specifically with respect to lazy initialization. My assumption is that
> those fields will be set to null between method calls, Gary
> assumes that the
> field may hold valid information (in which case lazy initialization dosn't
> occur). Comments?
>
> (we discussed doing a test, but that would only prove what Orion does ...)
>
> john d
>
