Why a pool of stateless EJB is needed

Question

I know that:

For stateless session beans the server can maintain a variable amount of instances in a pool. Each time a client requests such a stateless bean (e.g. through a method) a random instance is chosen to serve that request.

My question is: Why a pool is needed? Shouldn't one instance of a EJB stateless bean be enough to serve all requests ?

Also if the server for a given stateless bean is using a pool of 10 instances, is 10 the maximum number of requests it can handle on such a bean ?

Can you help me clear my doubt?

EDIT:

section 4.3.14 of the ejb 3.1 spec gives the answer.

4.3.14 Serializing Session Bean Methods The following requirements apply to Stateless and Stateful session beans. See Section 4.8.5 for Singleton session bean concurrency requirements.

The container serializes calls to each stateful and stateless session bean instance. Most containers will support many instances of a session bean executing concurrently; however, each instance sees only a serialized sequence of method calls. Therefore, a stateful or stateless session bean does not have to be coded as reentrant.

The container must serialize all the container-invoked callbacks (that is, the business method interceptor methods, lifecycle callback interceptor methods, timeout callback methods, beforeCompletion, and so on), and it must serialize these callbacks with the client-invoked business method calls.

Searching a bit online, my quess is that a thread pool is necessary to the specification that imposes that EJB stateless methods are thread safe. So if we have,say 10 beans in the pool, only 10 requests can be served simultaneously, the other will be queued and assigned to the first free bean. Please correct me if I'm wrong.

Answer 1

Single stateless EJB instance can handle all requests theoretically but too slow. Performance is main achievement in maintaining stateless EJB pool. Pool saves time in creating the EJBs and acquiring any predefined resources to process the incoming requests. Container guarantees the thread safe behavior so performance is really boosted with multiple ready instances in pool.

Also if the server for a ginen stateless bean is using a pool of 10 instances, is 10 the maximum number of requests it can handle on such a bean ?

With Pool of 10 instances can handle 10 simultaneous requests same time.

Answer 2

If you create a stateless session bean, It does not care about which client is calling, It allow you reuse the instances across multiple clients, with this you are going to have a better performance in your application, It is one of the principal differences between a stateless session bean and a stateful session bean.

A stateful session bean is going to create one instance per client and it is going to reduce the performance of the application because you are going to have many instances at the same time.

To have a pool allow you to increase the number of stateless ejb instancess depending of the load of your application :)

Edit

If you want only one instance to all the request and it is all that you need you can use a singleton session bean instead of a stateless session bean the stateless session bean was made for this operations that does not require of a state and this operation are going to help you to increase the performance.

If you have a pool with 10 instances you can receive any number of requests but only 10 instances are going to attend them .

Answer 3

Stateless EJB are not state-less. (duh?)

I explain. A stateless EJB has some states, such as a flag for know if the EJB is running/sleeping or if the EJB is loaded and so on. I.e., a stateless EJB has hidden fields.