> Using a stateless session bean for general caching is probably not a
> good choice for the reason you mentioned. However if the amount of
> data in the cache is small and there is no client specific data that
> is being cached, then I wonder if the stateless session beans may be
> appropriate. If for example each call to the stateless session could
> be delegated to a different instance of the stateless session bean
> than it may be appropriate to do this. In that case if there are many
> concurrent calls being made the calls could be delegated to different
> instances and no blocking would occur. If the amount of data in the
> cache is large this would not be appropriate because each bean would
> have to maintain copies of the data.
Dan, you lost me. If each request is delegated to a different instance,
totally at random as far as the application is concerned, where is the
cache?
>
> However, for stateless session beans I assume that concurrent calls
> are not allowed. This implies you should not use the same session
> bean object in 2 separate threads.
>
> myStatelessHome = (MyStatelessHome)narrow(initialContext.lookup(...),
> MyStatelessHome.class);
> stateless = myStatelessHome.create();
> (new MyThread(stateless)).start();
> (new MyThread(stateless)).start();
>
> public class MyThread extends Thread
> {
> private MyStateless myStateless;
> public MyThread(MyStateless x)
> {
> this.myStateless = x;
> }
> public void run()
> {
> //call methods on myStateless.
> }
> }
>
> The above code could generate an exception since concurrent calls on
> session beans are not allowed.
>
> However, there is a question about the following case:
>
> myStatelessHome = (MyStatelessHome)narrow(initialContext.lookup(...),
> MyStatelessHome.class);
> stateless1 = myStatelessHome.create();
> stateless2 = myStatelessHome.create()
> (new MyThread(stateless1)).start();
> (new MyThread(stateless2)).start();
>
>
> Will that be OK?
>
> I am not sure what the answer is because of the following 2 statements
> taken together from the spec:
>
> All session objects of the same stateless session bean within the same
> home have the same object identity, which is assigned by the
> container.
Identity is used for tracking uniquness. You can have multiple instances
per identity, both for stateless (the normal case) and for entity beans
(CMP allows that).
> and combine that with.
>
> 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.
>
> In one interpretation stateless1 and stateless2 are considered to be
> the same object. Perhaps however the use of "identity" in the first
> statement is not the same use of "identity" in the second statement.
> If that is the case then the above code would be OK.
>
> So what is the meaning of these two statements and which
> interpretation is correct? Where can one get "official"
> clarifications of the spec?
At least as far as "is in progress on an instance", the stateless model
allows you to choose a different instance for each method invocation, as
you quote down below. So you almost have a solutio, except for the first
line, of not being able to make concurrent calls on a session object
(regardless of which instance it maps to).
This in my opinion deserves clarification or at least good
justification.
> Now here comes the really confusing part. The spec also states:
>
> 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
> delegate 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.
>
> So if the first interpretation is correct it would seem that the
> container would never want to create multiple copies of the stateless
> session bean. There would be no use since the only reason to do that
> would be to improve performance on concurrent requests. But
> concurrent requests cannot happen because the spec states so.
The last part is a "may" not a "should". The container can choose to do
so, or choose not to do so, you are not guaranteed any specific
behavior. And it's not really for concurrent calls, it's simply a way to
have 500 remote interfaces piped into 50 bean instances. It allows the
server to have a limited pool of instances and service clients on
demand.
arkin
>
>
>
>
>
>
> >
===========================================================================
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".
