9

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.

GionJh
  • 2,742
  • 2
  • 29
  • 68
  • take a look on those links: http://www.adam-bien.com/roller/abien/entry/do_we_need_stateless_session and http://stackoverflow.com/questions/134791/why-pool-stateless-session-beans – Thiago Bonfante Jun 23 '15 at 20:37
  • I had already read that resources but I still not find a satisfactory answer... – GionJh Jun 23 '15 at 20:46
  • I have found in [this post](https://stackoverflow.com/a/1628202/267197) that EJB container "must ensure that one thread is executing instance at the same time", but "may interleave requests from multiple transactions to the same instance" – these two are contradictory as normally separate transaction = separate thread. I would vote that pools are introduced to implement fist, and time-saving on `@PreConstruct` is a free sweet supplement. – dma_k Jun 30 '17 at 12:55

3 Answers3

3

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 .

Alejandro Agapito Bautista
  • 1,344
  • 1
  • 15
  • 35
  • 1
    If you have a pool with 10 instances you can receive any number of requests but only 10 instances are going to attend them . So that means only 10 request can be processed simultaneously. – GionJh Jun 24 '15 at 10:18
  • @GionJh As the edit says, stateless session bean instance pools typically do not block requests when a hard upper limit is reached like a JDBC connection pool will. This depends on the implementation; for example, I know WebSphere Application Server can be configured to have a hard upper limit on the number of bean instances, but it's not the default. – Brett Kail Jun 24 '15 at 14:10
  • 1
    I think I don't fully understand...you man that if we have at a given time 10 stbs serving each serving one request and we get an 11th request another bean could be created in order to avoid queueing ?? – GionJh Jun 24 '15 at 17:00
2

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.

mjs
  • 139
  • 8
  • He asked "Shouldn't one instance of a EJB stateless bean be enough to serve all requests?". You explained the purpose of an object pool, but didn't explain why a single EJB can/can't serve all requests – Vince Jun 23 '15 at 20:57
  • "Single stateless EJB instance can handle all requests theoretically but too slow." why it is being slow? the single instance will run on a different thread. suppose 100 thread is running for a singleton object. on the other hand 10 stateless object handling same traffic with same number of thread. so performance will same or not ? – roconmachine Apr 20 '21 at 19:16
-2

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.

magallanes
  • 6,583
  • 4
  • 54
  • 55