Laird Nelson wrote:
> Kirk Pepperdine wrote:
> > From the 1.1 spec it would appear as if the container has the option of
> > delegating any method call from a client to any stateless session bean
> > that's in its pool. So each of foo, bar, and baz would run in a different
> > stateless session bean.
>
> Yes, and that has certainly been my experience, and that was what I
> thought as well.
>
> If that's true, which I sure hope it is in all servers, then Marc's
> comment (to which I was objecting) that "a client reference to a
> stateless session bean...ought to be good for some period of time" is
> sort of meaningless, or at least non-informational. That is, that
> reference only needs to be "good" for the life of the method invocation,
> which is quite obvious, or else the Java language wouldn't work. :-)
>
> I actually assumed he was saying something more, and something that
> troubled me, viz. that the reference had to be "good" for, say,
> something like five minutes, or three hours, or some other
> server-dependent timeout value (I believe he mentioned something about
> the timeout attribute that you set on the session bean? haven't gotten
> there yet) after which point it would no longer be "good", and after
> which point your client application might start behaving in
> unpredictable ways. Obviously, since the client application cannot
> predict the session timeout value in advance--it could be
> milliseconds!--the client app in such a bizarre system would have to be
> written assuming that the stateless session bean reference was *never*
> good, and would have to be looked up anew each time! I was desperately
> hoping he was wrong, because this would be a crummy way to design (a) a
> specification and (b) a server.
Let me try to clarify still further what I was getting at. I agree
absolutely with you - it would be lousy if clients couldn't count on their
references. The question is - for how long? Seconds or minutes would be
dumb. Hours would be perhaps typical. Days or weeks would be good. Should
it be years? What's the limit? Who determines the limit? If there shouldn't
be a limit, shouldn't the specification require that?
> And the bit that he writes about "after that time [i.e. the hypothetical
> five minutes or three hours] the reference should be cancellable" makes
> no sense to me. What would it mean to cancel a reference to a stateless
> session bean? How would you do this? What would happen? How could I
> possibly ever write a client application that would work?
"Cancelling" a reference just means that sending a message through it
yields some exception such as "no connection" or "object does not exist" or
"certificate expired" or the like. It's easy to implement ways to
re-connect, re-try, re-certify, and so on, but at some point the code
supporting the client reference has to know when it's time to give up.
Maybe the server's down. Maybe the application has been reinstalled. Maybe
the permissions on the application have changed. Some real world events, or
some system resource management events, or some security events, have
caused the world the client started with to change.
I'm talking about days and weeks here. I don't think we're on different
pages.
Marc San Soucie
GemStone Systems, Inc.
===========================================================================
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".
