Two Laptop Bag*
The moose likes EJB and other Java EE Technologies and the fly likes About stateless session bean pooling in EJB 3 in action (2nd edition) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "About stateless session bean pooling in EJB 3 in action (2nd edition)" Watch "About stateless session bean pooling in EJB 3 in action (2nd edition)" New topic
Author

About stateless session bean pooling in EJB 3 in action (2nd edition)

Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 781
In EJB 3 in action :

3.2.2 Stateless session bean pooling
...
It's almost always a good idea to specify a maximum pool size to safeguard against resource starvation caused by sudden bursts of concurrent
requests. The typical default value of maximum pool sizes is between 10 to 30.... you should set a maximum pool size matching the highest normally
expected number of concurrent users you have for a given service. Too low a number will make the application appear unresponsive with long wait queues, whereas too high a number will risk resource starvation under heavy load.....


Can anyone tell me why too high a number of stateless beans in the pool will cause resource starvation under heavy load?

If there are 20 concurrent requests and the number of beans is maximized to 100, 20 beans will handle requests and 80 beans are idle. Why resource starvation may happen?
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 475
    
    1

Himai Minh wrote:
Can anyone tell me why too high a number of stateless beans in the pool will cause resource starvation under heavy load?
If there are 20 concurrent requests and the number of beans is maximized to 100, 20 beans will handle requests and 80 beans are idle. Why resource starvation may happen?


Just because in front of a peak of requests, your appserver would instantiate 100 EJB instances instead of only 30 (for example) instance, would try to process all requestes instead of putting them in a queue
and wait for a EJB Thread available,or, eventually, until their time out.
This may eventually make your appserver go out of resources (memory; connections from connection pools). Of course this may depend on resources
actually available for your appserver (if you're running your Java EE on a monster machine with 200 GB of RAM and 64 cores dedicated to your appserver I think it would
very hard to bring it down) and on what your EJB methods are doing (if they all return an "Hello world" message there are not many resources involved, but of course
an EJB method invocation is likely to create transactions, use datasources, which are in turn limited resources)
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: About stateless session bean pooling in EJB 3 in action (2nd edition)