I already understood from a previous email that 6.5.6 applies only to stateful beans.
I was
asking from what in the spec would one be able to determine that? And more generally
what
sections of the spec apply only to stateful sesssion beans?
Vlada Matena wrote:
> 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".
===========================================================================
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".
