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()
> > > {
> > > //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".
