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.
The pooling of Entity Beans is a functionality to pool the Entity Beans based on the access volume from the client. In the EJB container, you create a pool for each Entity Bean and manage these pools. By specifying the maximum and minimum values, the pooling operation can be customized.
A stateless session bean is a type of enterprise bean, which is normally used to perform independent operations. A stateless session bean as per its name does not have any associated client state, but it may preserve its instance state.
Because they can support multiple clients, stateless session beans can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.
Stateful session beans maintain the state associated with a client. Each stateful session bean serves exactly one client. Stateless session beans are intended to be simple and lightweight; that is, they are easy to develop with low runtime resource requirements on the server.
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 .
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With