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".
