Stateful session bean timeout.
arkin
Kirk Pepperdine wrote:
>
> Frank,
>
> For statleless, it doesn't matter. For statefull, then you've got
> problems. What happens if clients go away without calling
> remove. Is the server obliged to maintain that statefull session
> bean forever?
>
> Kirk
>
> -----Original Message-----
> From: Frank Sauer <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Saturday, January 15, 2000 2:05 AM
> Subject: Re: Stateless Session Beans
>
> >I think we're all forgetting that a client has a reference to a stub,
> >not the bean itself. This reference stays good, but resolves to different
> >bean instances on the server for possibly each method call. Is this
> correct?
> >
> >How long will a stub remain valid (allow connections to possibly
> >different instances on the server)? I have no clue... session bean
> >time out as set in the DD seems like a reasonable value.
> >
> >
> >Frank Sauer
> >The Technical Resource Connection
> >http://www.trcinc.com
> >------------------------------------------------
> >Java: The best argument for Smalltalk since C++
> >
> >-----Original Message-----
> >From: A mailing list for Enterprise JavaBeans development
> >[mailto:[EMAIL PROTECTED]]On Behalf Of Marc San Soucie
> >Sent: Friday, January 14, 2000 6:10 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Stateless Session Beans
> >
> >
> >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".
> >
> >===========================================================================
> >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".
