It seems to me that you are worried about this piece of the spec:
<spec>
Because all instances of a stateless session bean are equivalent, the
container can choose to delegate a
client-invoked method to any available instance. This means, for
example, that the Container may dele-gate
the requests from the same client within the same transaction to
different instances, and that the
Container may interleave requests from multiple transactions to the same
instance.
</spec>
But note that this is in the Stateless session bean section of the spec
(6.8) and this just means that client A and client B can access the SLSB
in turn, not at the same time. This is clear from section 6.11.6:
<spec>
6.11.6 Non-reentrant instances
The container must ensure that only one thread can be executing an
instance at any time. If a client
request arrives for an instance while the instance is executing another
request, the container must throw
the java.rmi.RemoteException to the second request.
Note that a session object is intended to support only a single client.
Therefore, it would be an
application error if two clients attempted to invoke the same session
object.
One implication of this rule is that an application cannot make loopback
calls to a session bean instance.
</spec>
So client A and B may not access the same SLSB object at the same time.
Method requests from client A and client B may, however, be interleaved
on a SLSB object.
>>From: "Papaya Head" <[EMAIL PROTECTED]>
>>
>> I see nowhere it mentions threads and concurrency,
>> but "the number of instances required to service the
>> current client load" sounds clear to me that it means
>> one client request maps to one stateless session bean
>> instance?
>>
>I agree that conventional wisdom and my real-life experiences with
different
>products agree with your conclusion, but I don't think this is an area
where
>the spec is gray. I think it says specifically, that bean providers can
>expect two threads to be executing concurrently in the same instance of
a
>SLSB.
>
>They really should clear this issue up. I haven't ever written a SLSB
where
>I was concerned with concurrency.
>
>jim
>
--
Tom
Thomas Preston
Vacation.com, Inc.
Engineering Department
617.210.4850 x 124
===========================================================================
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".
