Originally posted by chinababu illa:
What my doubt is, if we let the stateful session bean associate to the client as long as the client is calling, but once this has to be removed, instead of removing, we can send this stateful bean to the pool. In this case, stateful session bean also doesn't not have any state. And next time, another client comes for the stateful bean, bean has to come from the pool. This way, why can't the scalability be more, also for stateful sesson bean?
If at all the pooling is possible for stateful session beans, the container has to predict the *final* state of the bean, and then assign an appropriate instance from the pool. To add, this requires making a container super-intelligent to predict what the client will actaully do with the bean. Assigning just a new instance from the pool, will squeeze
*neither* the requests *nor* the time taken by the bean object to reach from state A to state B.
My understanding is scalability is the measure of threads that can be running concurrently per client, in a way that every instance in the bean-pool has equal load. To give you a picture lets say that max pool size is m and there are n clients.
For stateful session bean there can be only 1 thread per client running in the container, assuming every bean objects maintains equal load.
For stateless session bean, container can be executing a max of m threads per client concurrently such that every bean object gets an equal load.
This is as good as saying, statless session bean has been serviced m times faster than stateful bean, if they start at the same time. Hope that clears the picture.
[ June 24, 2006: Message edited by: Nishant Verma ]