I would recommend keeping it stateless, and trying to figure out how the
server could handle the load better.
Stateless session beans are more efficient due to this recycling
implementation. As I said, an EJB server is supposed to handle 500
clients with 50 sessions. If you're using stateful you will need 500
sessions for 500 clients, might be more than what your server wants to
handle.
That is why I proposed going through the JNDI. It's not the way it
should be done, but it might fix the problem. I will not propose
switching to stateful beans since this attempts to override a server
implementation bug with a less-than-optimal application implementation.
arkin
John Kidd wrote:
>
> 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".
===========================================================================
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".
