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