Kirk,
There is a sessionTimeout for the bean, at least in WebLogic. The problem we have
ran into is
when a bean times out, it passivates and according to the 1.0 spec a passivate bean
cannot be removed.
The 1.1 spec was changed to allow for the removal of passivated beans. We have a cron
job to remove
passivated beans that have timed out. Hope this helps.
Mark
>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".
