Hi Ana,
I think the container decides whether to maintain the
pool of objects for a stateless bean or to serialize
access to the bean.
Vendors, any comments on how it is implemented? In
fact, does the deployer have an option to configure
that?
-- D Swaminathan
--- "Bhattacharyya, Ana"
<[EMAIL PROTECTED]> wrote:
> 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
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
===========================================================================
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".
