?? 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".
