Yeah I know. I think I am going to move this to StateFul....



                    Assaf Arkin
                    <[EMAIL PROTECTED]        To:     [EMAIL PROTECTED]
                    OM>                      cc:
                    Sent by: A               Subject:     Re: Stateless Session Beans
                    mailing list for
                    Enterprise
                    JavaBeans
                    development
                    <EJB-INTEREST@jav
                    a.sun.com>


                    01/12/00 01:50 AM
                    Please respond to
                    A mailing list
                    for Enterprise
                    JavaBeans
                    development






There's different semantics with stateless session beans that what you
expect with CORBA objects.

If you refer to pages 67/68 of the specs you will see that calls to
create/remove to not really create/remove the bean itself, and that the
container can choose to delegate the invoke method to any available
instance of the session bean (if one is available).

So pretty much your handle into the bean does not mean there's a bean on
the other side to handle it. If the server decides to only create 50
beans, you can still create 51 (and even 500) handles. As long as you
only use 50 at once everything is fine. Once you get to use number 51
concurrently, the server runs out of beans in the pool.

A good server will keep you holding for a few seconds until a new bean
becomes available, or will give you a better explanation in the
exception.

You can always try to increase the size of the pool, but that's a brute
force approach which goes against the EJB design.

arkin


John Kidd wrote:
>
> Unfortunately the piece making the call is a thin CORBA wrapper around
the
> EJB server. So I am getting the Objects locally. (Performance is
> significantly better).
>
> Any other thoughts?
>
> -John
>
>                     Assaf Arkin
>                     <[EMAIL PROTECTED]        To:
[EMAIL PROTECTED]
>                     OM>                      cc:
>                     Sent by: A               Subject:     Re: Stateless
Session Beans
>                     mailing list for
>                     Enterprise
>                     JavaBeans
>                     development
>                     <EJB-INTEREST@jav
>                     a.sun.com>
>
>                     01/11/00 11:55 PM
>                     Please respond to
>                     A mailing list
>                     for Enterprise
>                     JavaBeans
>                     development
>
> Assume that a stateless bean only exists for the duration of a method
> call. After you're done with it, the bean is disposed of (or reused by
> someone else). Before calling a bean, always look it up through JNDI.
>
> This will not only solve your problem of beans dying up on you, it will
> also allow the EJB server to load balance between two machines, and
> properly recycle a small set of beans across a large number of clients.
>
> arkin
>
> John Kidd wrote:
> >
> > I have three Stateless Beans in an application. They purely act as
> > middleware to several backend systems. What I am seeing is that when I
> > start stressing it will a lot of clients sometimes a client will call a
> > method on a bean that no longer exists. I get a
> > java.rmi.NoSuchObjectException. What is going on?? I thought the
> container
> > was supposed to manage this? Do I need some type of transaction
> > demarcation? Help!
> >
> > -John
> >
> >
>
===========================================================================
> > 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".

Reply via email to