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