Thanks for getting us back to the spirit of the original post, Assaf.
I see problems with Gemstone's (and others that destroy EJBObjects)
implementation. They have been touched on before, but let me reitterate.
- Note: All mention of session beans below, refer to *stateless* session
beans.
- It is common for clients (real clients, session beans, and entity beans)
to keep a reference to a stateless session bean's remote object.
- If that reference can be voided at some future time by the server the
client must either:
a. get a new reference in each method that utilizes the bean. I believe this
to be a serious performance problem. JNDI lookups can occur to a variety of
backend data stores (COS Naming, LDAP, etc.).
b. to allieviate the performance problem in (a), one could store the last
time the reference was retrieved. If the next use of that reference exceeds
X minutes, the reference is looked up again. X would have to be specified by
the deployer via a parameter to account for whatever timeout value was
specified on the server.
c. Every individual method call on the stateless session bean would have to
be wrapped in a try/catch block, with the sole purpose to refetch a
connection to the bean if a certain exception is thrown. BTW, just what is
that exception, NoSuchObjectException? RemoteException? EJBException? Will
all containers throw the same exception, and we be able to distinguish the
exception from other non-application exceptions?
It is well documented that a client reference to a session bean's EJBHome
object can be reused very far in the future. Also, the actual instance of
the stateless session bean can be destoyed by the container at will. It is
really not too important. I know that some containers (Inprise IAS) does not
*ever* destroy stateless session bean instances.
I guess the real question involves the server-side EJBObjects. Marc was
stating that Gemstone (correct me if I'm wrong) destroys these resources
after a suitable timeout period. Do all containers employ this mechanism? Do
we as developers have to use one of the methods I outlined above, or are
there better approaches?
jim
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Assaf Arkin
> Sent: Sunday, January 16, 2000 9:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Stateless Session Beans
>
>
> Marc's point was lost in the noise, sorry Marc.
>
> There's a major difference between stateful and stateless. Stateless
> don't have to exist in order for you to reference them and invoke them,
> they are created on demand. The EJB server can dispose of stateless
> instance beans when no method calls are made on them, whether or not a
> remote reference is held by the client.
>
> Stateful beans exist as long as they are referenced, and as long as at
> least one client keeps a reference to the bean instance it must exist.
> Garbage collection doesn't work here, since we're talking distributed,
> so the instance will be released if one of the following happens:
>
> * The client remembers to call remove
> * Enough time has passed for the bean to be disposed of
>
> With stateful beans you will want to dispose of them fairly early, e.g.
> after 20 minutes of inactivity. With stateless beans you will not want
> to dispose of them, but don't expect to hold a reference that is valid
> for days or weeks.
>
> I assume that was Marc's point. Marc?
>
> arkin
>
>
>
>
> Kirk Pepperdine wrote:
> >
> > 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".
>
> ==================================================================
> =========
> 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".
