CODEWITHSUNDEEP
webspherewebsphere-8
Krishna Chaitanya
Krishna Chaitanya

Reputation: 2663

Websphere ejb pool

The documentation here http://www.ibm.com/support/knowledgecenter/SS7JFU_7.0.0/com.ibm.websphere.express.doc/info/exp/ae/rejb_ecnt.html mentions that a minimum of 50 and a maximum of 500 instances are created by default per ejb.

Lets say at a given point of time 500 clients are trying to use the service. Does it mean that from here after at any time there will be 500 instances? Or will the server destroy the instances after a period of time and when there are no incoming clients?

After reading further I came across something called hard limit H which forces/tells the container not to create more than the specified maximum number of instances.

So what I understood in case of 50,500 is

  1. At any point there will be max number of instances(500).
  2. If more clients are trying to connect, the server will create a new instance(501, 502, 503....) per client and destroy it after serving the client.

Can anyone tell me if I am right?

Upvotes: 0

Views: 451

Answers (1)

Haxiel
Haxiel

Reputation: 693

Pooling EJB instances allow you to save system resources. Let's say that you need 100 instances of the EJB at a given point. You initialize the beans, process the logic and then destroy them. If you need an additional 100 instances after that, you need to do this all over again. This puts a strain on system resources.

When you pool EJB instances, they move in and out of a pool that is maintained by the EJB container. Active instances process the incoming requests, while passive ones stay in the pool. To control the size of the pool, there should to be an upper and lower bound on the number of instances within the pool.

Consider the default setting: The minimum is 50 instances and the maximum is 500 instances. When the server starts up, there are no instances of the EJB on the server. As your application gets concurrent requests/hits, the pool size increases. Let's assume that there are 30 concurrent hits. The pool size stays at 30. WebSphere will not create additional instances to maintain the pool size at the minimum value. After that, assume that the concurrent hits increase to 75 and then drop below 50. At this point, WebSphere will destroy the additional 25 EJB instances and maintain the pool size at 50. Now, if you define the lower limit as 'H50' (hard limit), WebSphere will expend resources to create 50 EJB instances as the server/application starts up. Therefore, the pool size will never drop below 50.

Now let's look at the upper limit, which is 500. As the number of concurrent hits increases, the pool size grows and exceeds 500. Beyond this limit, WebSphere tries to lower the pool size by destroying the EJB instances as soon as they become inactive (i.e. return to the pool). However, the EJB instances can continue to grow beyond this limit. If you have 600 concurrent requests, there will be 600 EJB instances. If it falls to 540, the additional 60 beans are destroyed. The hard limit ('H500') ensures that this overflow never happens. Upto 500 concurrent requests can be handled at the pool's maximum size. Additional requests must wait until an EJB instance becomes inactive (i.e. returns to the pool).

Upvotes: 1

Related Questions