James,
There is another problem with the code you shared. Since servlets are
multithreaded (many threads may be running through this servlet at the same
time), you need to mutex around the bean (better yet instantiate a pool of
bean references in your servlet and dole them out to threads as required.
The doling has to be synchronized, but the invocations on the doled out
beans would not).
I think the earlier point was made in this thread that since you have to
fence around RemoteExceptions for your bean and handle service failures in
general, it's really kind of a moot issue.
I'll let someone else at GS respond to the EJB Object issue since I am
actually unaware of the details. This has not come up in any of my
customers...
Regards,
-Chris.
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 20, 2000 4:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Stateless Session Beans
>
> ?? I'm referring to stateless session beans. Take an example...suppose I
> have a servlet that performs the following pseudo-code tasks in its init()
> method (one time only - at servlet startup:
>
> private LoginRemote login = null;
>
> init() {
> LoginHome home = lookup("loginBean");
> LoginRemote login = home.create(); // <-- pseudo-code
> }
>
> Now my servlet makes liberal use of the login.validate(username, password)
> in it's doGet method. What you are saying in your post is that I shouldn't
> care what the server is doing to the actual instances of "LoginBean", and
> you are right. I don't care.
>
> What I'm questioning is the position Gemstone (and perhaps others) take
> regarding the validity of "login", my reference to a local stub class that
> wishes to communicate with a remote EJBObject. If I understand, Gemstone
> will not guarantee that my call to login.validate(username, password) will
> succeed, because the server-side EJBObject may of been discarded.
>
> I am assuming that your stub will not negotiate automatically for me to a
> new EJBObject. Maybe it does, and this is all mute.
>
> I can code around a service failure. I just want to know if I understand
> the
> problem. The spec is obviously vague about this. If true, a remote call in
> any business method will have to be prepared to call home.create() if a
> particular exception is thrown. BTW, do you guys throw
> NoSuchObjectException
> under these circumstances?
>
> jim
>
> ----- Original Message -----
> From: Kirk Pepperdine <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 19, 2000 11:58 AM
> Subject: Re: Stateless Session Beans
>
>
> > Jim,
> > I'm not sure how of what you believe the problem is. First I thought
> > that we were talking about stateless session beans. I believe that
> > earlier postings established that that the client shouldn't be aware
> > of or care what the server is doing. As users of EJB servers all we
> > want is for our clients to have their requests serviced in a timely
> manner.
> > I can't speak for the Inprise implementation of this requirement but
> > GemStone offers a multi VM solution. Not only will GemStone reap
> > session beans, it may reap VMs. The client is never aware of this
> > activity. And.. I don't believe this is a violation of the spec.
> >
> > Kirk
> >
> > -----Original Message-----
> > From: Marc San Soucie <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > Date: Monday, January 17, 2000 11:36 PM
> > Subject: Re: Stateless Session Beans
> >
> >
> > >James Cook wrote:
> > >
> > >> I guess the real question involves the server-side EJBObjects. Marc
> was
> > >> stating that Gemstone (correct me if I'm wrong) destroys these
> resources
> > >> after a suitable timeout period.
> > >
> > >I was stating that an EJB server, on request from an administrator
> > >using a technique such as a configurable timeout, should be able to
> > >eliminate client-specific artifacts that are "out of date". Some
> > >folks interpret the EJB spec to say that client references to
> > >stateless session beans are never "out of date". The spec doesn't
> > >say this, but it's certainly one possible interpretation.
> > >
> > > Marc San Soucie
> > >
> >
> >=========================================================================
> ==
> > >To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > >of the message "signoff EJB-INTEREST". For general help, send email to
> > >[EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
> ==========================================================================
> =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
