Stateful beans are not pooled, since the state of the bean is per client.
They may be passivated and activated by the server to conserve resources
though...
-Chris.
> -----Original Message-----
> From: Bhattacharyya, Ana [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 09, 2000 8:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Concurrency in stateless session beans
>
> Hi
> I have a question here. Everywhere it is written stateless session beans
> give better performance compared to stateless session beans. I was just
> wondering how the conatiner handles the stateless and stateful session
> beans. As far as I understand the container creates a pool of session
> beans
> independent of whether it is a stateless/stateful. Now in case of
> stateless
> session bean two successive calls from a client with the same objref can
> be
> redirected to a two diffterent pooled instances of the stateless bean. But
> in case of stateful beans --- it has to directed to the same instance of
> the
> stateful bean --- and this is what causes the performance degradation
> compared to stateless beans???
> or is it that in case of stateful beans -- the container does not pool it
> at
> all -- and when a client is using it all the other clients are in a queue.
> but that will be really a bad implementation!!!!.
> pls enlighten me on this topic.
> TIA
> Anamitra
>
> -----Original Message-----
> From: dan benanav [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 29, 2000 11:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Concurrency in stateless session beans
>
>
> It does not serialize calls to objects but serializes calls to beans.
> Consider the following:
> public AThread extends Thread
> {
> private ARemoteObj myRemoteObj;
> public AThread(ARemoteObj obj){myRemoteObj = obj;}
> public void run()
> {
> myRemoteObj.methodCall();
> }
> }
> So for example what will the container do in the following case:
>
> remoteObj1 = home.create();
> thread1 = new AThread(remoteObj1);
> thread2 = new AThread(remoteObj1);
> thread1.start();
> thread2.start();
>
> Will and exception be generated?
> 1) If remoteObject is a session object - Yes it might.
> 2) If remoteObject is a stateless object - no
> 3) If remoteObject is an entity object - no.
>
> In case number 2 each call to remoteObj might be delegated to different
> stateless session bean instances. If the container doesn't have one
> available I
> assume it will create one. But if the maximum number is set (If the ejb
> server
> allows that) then I assume the container will wait until a stateless
> session
> bean becomes available.
>
> What the ejb standard doesn't say is whether an ejb server should provide
> a
> means whereby the application developer can set the maximum number of
> stateless
> beans that get created. If that were possible then a kind of singleton
> can
> be
> created.
>
>
>
>
>
>
> "Louth, William (Exchange)" wrote:
>
> > You said this:
> >
> > > > To answer your question, which actually applies to both stateful and
> > > > stateless session beans, EJB does not provide a way to serialize
> calls.
> > > > To me this is a major weakness of EJB.
> >
> > I responding by saying that this would kill a system if implemented.
> Pleaese
> > explain how it would not.
> >
> > William
> >
> > > -----Original Message-----
> > > From: dan benanav [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, February 29, 2000 2:34 PM
> > > To: Louth, William (Exchange)
> > > Subject: Re: Concurrency in stateless session beans
> > >
> > > Why do you think this would be a performance problem? To the contrary
> > > everything is cached so it should be quick. The improve performance
> you
> > > can
> > > keep multiple copies of the cache by allowing many stateless beans.
> > >
> > > The email message you included below is actually something I wrote and
> > > refers to
> > > stateful beans, not stateless beans.
> > >
> > > dan
> > >
> > > "Louth, William (Exchange)" wrote:
> > >
> > > > Your major weakness sounds like a major performance problem if
> > > implemented.
> > > > Please explain why this feature is so needed.
> > > >
> > > > William
> > > >
> > > > > -----Original Message-----
> > > > > From: dan benanav [SMTP:[EMAIL PROTECTED]]
> > > > > Sent: Sunday, February 27, 2000 3:28 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: Concurrency in stateless session beans
> > > > >
> > > > >
> > > > >
> > > > > Jose Gonzalez wrote:
> > > > >
> > > > >
> > > > > The EJB specification states that a single instance of an EJB
> > > cannot
> > > > > receive concurrent calls, and that the container must serialize
> calls,
> > > > > but I understand that this is the desired behaviour in case of a
> > > program
> > > > > invoking methods on an stateful session bean, not in the case of
> > > > > invoking methods on stateless session beans...
> > > > >
> > > > > Am I right? Is NetDynamics doing right according to the EJB
> specs?
> > > > > If yes... how could I achieve concurrency on calls on an stateless
> > > > > session bean?
> > > > >
> > > > > Actually the container is not responsible for serializaing calls
> to
> a
> > > > > stateful session bean in the way you think. For example suppose
> > > threadA
> > > > > and threadB are running concurrently and each thread makes the
> > > following
> > > > > invocation.
> > > > >
> > > > > myStatelessSesssion.foo();
> > > > >
> > > > > So each thread is making a call on the same method and the same
> entity
> > > > > object. In that case the container should (according to the spec)
> > > throw a
> > > > > RemoteException.
> > > > >
> > > > > So you may be wondering what is the meaning of the phrase,
> > > > > "A container must serialize calls to the session bean". The spec
> is
> > > > > talking about calls that the container makes to the session bean
> > > instance
> > > > > not calls made to the session object. Note that the container
> will
> > > make
> > > > > calls like ejbLoad, ejbActivate, and ejbPassivate in addition to
> calls
> > > to
> > > > > the business methods.
> > > > >
> > > > > To answer your question, which actually applies to both stateful
> and
> > > > > stateless session beans, EJB does not provide a way to serialize
> > > calls.
> > > > > To me this is a major weakness of EJB.
> > > > >
> > > > > dan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Greetings
> > > > > Jose
> > > > >
> > > > >
> > >
> ==========================================================================
> > > > > =
> > > > > 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".
> > > > >
> > > >
> > > >
> ***********************************************************************
> > > > Bear Stearns is not responsible for any recommendation,
> solicitation,
> > > > offer or agreement or any information about any transaction,
> customer
> > > > account or account activity contained in this communication.
> > > >
> ***********************************************************************
> >
> > ***********************************************************************
> > Bear Stearns is not responsible for any recommendation, solicitation,
> > offer or agreement or any information about any transaction, customer
> > account or account activity contained in this communication.
> > ***********************************************************************
>
> ==========================================================================
> =
> 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".
