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