Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Stateful and Stateless - Pooling

 
chinababu illa
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I'm new to this group. I'm going to give the SCBCD exam soon.
I've one doubt in scalability of Stateful and Stateless session bean.
Stateless session beans are more scalable than Stateful session beans, because, stateless beans are pooled. Pooling concept is not implemented for stateful sesson beans because it has to maintain the state, and once the bean goes to the pool, bean doesn't keep any state. So, stateful session bean are removed from the memory, once it's job is done.

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?

Could any one please clarify my doubt.

Thanks in advance.
Chinna
 
Nishant Verma
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Thanks
Nishant
[ June 24, 2006: Message edited by: Nishant Verma ]
 
chinababu illa
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nishant,

Thanks so much. I was in the misconception of scalability. you made it clear.

Chinna
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic