6.5.6 applies to stateful session beans only.
We intended that for a stateless session bean, the container could dispatch a request
on
another available instance of the bean class (it cannot dispatch on an instance that
has another request in-progress).
Vlada
----- Original Message -----
From: dan benanav <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 27, 2000 6:09 AM
Subject: Re: "Official" clarification of the ejb specification.
> 0) I still don't know where one goes to get an official clarification of the
> spec. Does anyone know the answer to that? Is the answer send to ejb-interest
> and wait for clarification from a sun representative?
>
> Still unanswered are:
>
> 1) What sections of the spec (1.1) apply only to stateful session beans?
> 2) How does one know that 6.5.6 applies only to statefule beans?
>
>
>
> dan benanav wrote:
>
> > Ken,
> >
> > It is not obvious at all from the spec the 6.5.6 applies only to stateful
> > beans. Is that something that should be inferred or is it explicitly
> > stated in the spec?
> >
> > Can I consider your answer the "official" answer?
> >
> > On a side not it is interesting how many misinterpretations of the spec
> > there are by ejb server vendors, authors and application programmers. For
> > example there appears to be a misconception regarding concurrent calls and
> > stateful session beans. As you mentioned below the container should throw a
> > RemoteException if a client or multiple clients make a concurrent call to
> > the session object. I believe this misconception arises because in another
> > section of the spec it states that the container serializes calls to the
> > session bean. I believe that the spec is referring to calls like
> > ejbPassivate and other calls that the container makes in addition to the
> > business methods.
> >
> > I have heard, but haven't tried it myself, that WLS will simple block on
> > concurrent calls to a session bean. I'm not sure how it works in 5.0 of
> > WLS.
> >
> > Kenneth Saks wrote:
> >
> > > Dan,
> > > Case b) is listed in the Stateful Session Bean section of the EJB
> > > spec(6.5.6)
> > > It can only happen for stateful session beans because there is only
> > > one instance per client, regardless of the number of invocations. In
> > > other
> > > words, each call to create() results in a single bean instance. It is
> > > the
> > > responsibility of the client to ensure that concurrent invocations are
> > > not made
> > > on that instance. Otherwise, the container will throw an exception.
> > > For stateless session beans, the container creates as many
> > > instances as are necessary to service the current "client load".
> > > Most containers make heavy use of instance pooling for stateless
> > > session beans, so they only need to have as many instances as
> > > the maximum number of concurrent invocations, even if the total
> > > number of invocations over time is much larger. Technically, the
> > > container could create a single instance of a stateless session bean
> > > and serialize access to it. Other than reduced performance, it
> > > would be transparent to the client.
> > > Both of your code snippets are equivalent and should work
> > > fine.
> > > The EJB-INTEREST group is another good place for specific EJB
> > > questions. The discussion there is mostly spec-related.
> > >
> > > --Ken
> > >
> > > Kenneth Saks
> > > J2EE RI Core Team, Java Software
> > > SUN Microsystems
> > > [EMAIL PROTECTED]
> > >
> > > dan benanav wrote:
> > >
> > > > Where can I ge definitive answers and clarifications of the ejb spec?
> > > >
> > > > More specifically I have the following question and would like an
> > > > "official" answer to it.
> > > >
> > > > 1) The spec states:
> > > > a) All session objects of the same stateless session bean within the
> > > > same home have the same object identity, which is assigned by the
> > > > container.
> > > >
> > > > and also
> > > >
> > > > b) Clients are not allowed to make concurrent calls to a session
> > > > object. If a client-invoked business method is in progress on an
> > > > instance when another client-invoked call, from the same or different
> > > > client, arrives at the same instance, the container must throw the
> > > > java.rmi.RemoteException to the second client.
> > > >
> > > > If the sense of identity in a) and b) are the same, then the two
> > > > statements taken together would mean that only one client can invoke a
> > > > method on a stateless session bean at a time. For example the
> > > > following code could generate an error.
> > > >
> > > > myStatelessHome = (MyStatelessHome)narrow(initialContext.lookup(...),
> > > > MyStatelessHome.class);
> > > > stateless1 = myStatelessHome.create();
> > > > stateless2 = myStatelessHome.create()
> > > > (new MyThread(stateless1)).start();
> > > > (new MyThread(stateless2)).start();
> > > >
> > > > public class MyThread extends Thread
> > > > {
> > > > private MyStateless myStateless;
> > > > public MyThread(MyStateless x)
> > > > {
> > > > this.myStateless = x;
> > > > }
> > > > public void run()
> > > > {
> > > > file://call methods on myStateless.
> > > > }
> > > > }
> > > >
> > > > But that goes against much of what the spec states about using
> > > > multiple instances of stateless session beans. If the above reasoning
> > > > where true than multiple instances would never be required since
> > > > concurrent calls would only generate an exception.
> > > >
> > > > So what is the meaning of b).
> > > >
> > > > 1) It doesn't apply to stateless session beans at all. It is legal
> > > > for concurrently invoke methods on stateless session beans. If so
> > > > does the container need to serialize the calls?
> > > >
> > > > 2) It applies but the sense of identity is the normal sense and not
> > > > that described in a).
> > > >
> > > > For example the code above would be OK but the following would not.
> > > >
> > > > myStatelessHome = (MyStatelessHome)narrow(initialContext.lookup(...),
> > > > MyStatelessHome.class);
> > > > stateless = myStatelessHome.create();
> > > > (new MyThread(stateless)).start();
> > > > (new MyThread(stateless)).start();
> > > >
>
> ===========================================================================
> 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".
