Why pool Stateless session beans?

Question

Stateless beans in Java do not keep their state between two calls from the client. So in a nutshell we might consider them as objects with business methods. Each method takes parameters and return results. When the method is invoked some local variables are being created in execution stack. When the method returns the locals are removed from the stack and if some temporary objects were allocated they are garbage collected anyway.

From my perspective that doesn’t differ from calling method of the same single instance by separate threads. So why cannot a container use one instance of a bean instead of pooling a number of them?

Paduasoy

Answer 1

Pooling does several things.

One, by having one bean per instance, you're guaranteed to be threads safe (Servlets, for example, are not thread safe).

Two, you reduce any potential startup time that a bean might have. While Session Beans are "stateless", they only need to be stateless with regards to the client. For example, in EJB, you can inject several server resources in to a Session Bean. That state is private to the bean, but there's no reason you can't keep it from invocation to invocation. So, by pooling beans you reduce these lookups to only happening when the bean is created.

Three, you can use bean pool as a means to throttle traffic. If you only have 10 Beans in a pool, you're only going to get at most 10 requests working simultaneously, the rest will be queued up.

Henricks

"One, by having one bean per instance, you're guaranteed to be threads safe (Servlets, for example, are not thread safe)." How does being thread safe help in a stateless session bean ? – Epanodos

I don't understand what you mean when you assert Servlets are not thread-safe. IIRC, the Tomcat management console allows me to pool Servlets too. – Forwards

Stateless Session Beans are simple components. They can have "State", but the state is related to the component, not to the client. The bean has a full lifecycle. So, you could have a local cache, for example, in the bean and never worry about synchronizing it. – Henricks

Tomcat may offer a Servlet instance pool, but the spec doesn't require it. You can't assume that a specific servlet instance will only be accessed by a single request at a time. – Henricks

It might be clearer to say that the developer is responsible for writing a threadsafe servlet -- there will be multiple threads hitting it simultaneously. The stateless session bean does NOT need to be written to be threadsafe, because this is already guaranteed by the container (there will not be multiple threads executing simultaneously; instead there are multiple beans, pooled). – Unused

Answer 2

The transactionality of the Java EE model uses the thread context to manage the transaction lifecycle.

This simplification exists so that it is not necessary to implement any specific interface to interact with the UserTransaction object directly; when the transaction is retrieved from the InitialContext (or injected into the session bean) it is bound to a thread-local variable for reuse (for example if a method in your stateless session bean calls another stateless session bean that also uses an injected transaction.)

Cave

Answer 3

Pooling enhances performance.

A single instance handling all requests/threads would lead to a lot of contention and blocking.

Since you don't know which instance will be used (and several threads could use a single instance concurrently), the beans must be threadsafe.

The container can manage pool size based on actual activity.

Giga

Answer 4

Methods by nature ARE THREAD SAFE (including static). Why? Simple, because every variable inside the method is created in the stack memory, i.e. every variable used inside the method is created per call (it's not shared). However, parameters aren't part of the stack.

However, a method is unsafe if it uses an unsafe variable:

a) calling a static field or variable. However, it happens in every single case.

b) calling a resource that it's shared. Such as the EntityManager.

c) passing a parameter that is not safe.

Surber

Answer 5

Life cycle of the Statelesss session beans are Doesnot exist, Passive and MethodReady(Passive or Inactive) state.To optimize on perormance, instead of traversing the bean all through from create to method ready state, container manages the bean between active and passive states through the container callbacks - ejbActivate() and ejbPassivate() there by managing the bean pool.

sreenut

Rowan