I am getting lost in this reponse. Let me try to be more specific. If all
servlet requests are piped to the same bean by the servlet, and these
invocations are synchronized to avoid parallel invocations against the bean
(which are disallowed per the spec), then requests against the bean will
queue and the bean becomes a bottle neck. The EJB server can do all the
instance pooling magic it wants, but if the requests queue at the EJB
objects stub, then it does no good.Given the current spec, my advice is to use a stateful bean per servlet
session context (if stateful semantics are required) or a pool of session
bean references in the servlet engine so that multiple servlets can invoke
against pooled instances in parallel.Are we on the same page?
-Chris.
The original post discussed the problem with using a session bean
which is referenced from an HttpSession object. This is not good
since the HttpSession object may be used concurrently by more than one
thread.
For session state, blocking is probably not a problem because the concurrent calls only occur when the user has more than one window open in a browser or more then one frame in a window. Typically that will be a low number, so blocking will not be a bottleneck.
More than anything it is the multiple frames that can cause a problem. Even if the user has more than one window open at a time he can't click on more then one window at a time. However that number will still be small so synchronized calls will not be a bottleneck.
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.
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.
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?
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.
