Don't the point being made in this thread reflect what
Marc talked about in his note?
Kirk
-----Original Message-----
From: Assaf Arkin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sunday, January 16, 2000 12:15 PM
Subject: Re: Stateless Session Beans
>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".
===========================================================================
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".
