Why does Stateless Session Beans need pooling?

[Mauricio Rocha]

Hi, I wanna know if somebody has some explanation about why does SLSBs need pooling. What are it's benefits? Couldn't it be one instance per JVM? Since you don't need to keep any conversational state... Isn't it useless having many instances of the same class on server's memory?

[Jeanne Boyarsky]

Mauricio,
Only one SLSB can execute a request at a time. Suppose you have 10 requests per minute and each takes 30 seconds. If there was only one class, it would be a bottleneck because requests would be coming in faster than one SLSB could handle them. If there was a pool of 5-7 beans, multiple requests could execute simultaneously.

[Kenneth Gustafsson]

Also creating processes, threads and new object instances traditionally are expensive operations. I don't think the difference is as big in Java as in for example C/C++.

Still, object creation is pretty expensive and if you have a pool of already created objects running in their own threads ready to go, you save a lot of time and (garbage handling) time from creating (and destroying) threads and objects when needed.

[Roger Chung-Wee]

The EJB specification allows for, but does not require, bean pooling. I suspect that pooling of beans is now not particularly useful as modern JVMs create objects quite quickly.

What is much more helpful is pooling of objects which take a long time to get created, such as JDBC connections.

[Bill Shirley]

Stateless beans don't require pooling. The spec allows the containers to pool instances, if it desires. This information is (in my opinion) not useful information to provide to new coders and is over-covered by books on EJB.

Even if instance creation is not too bad, it is something, and if you have a highly scaled application - receiving 1000s of calls per minute - the repetitive code of creating and destroying is not necessary. This is the main purpose of the distinction between stateless and stateful. It also means, you shouldn't worry about bloating the size of your bean or the complexity of instantiating it.


@Kent - I'm thinking that object instance creation in C doesn't cause much overhead

[Aditya Jha]

Hi,

Only one SLSB can execute a request at a time.

Actually, this is the crux of the problem. Even though one instance would suffice in case of multi-threading, JVM specification ensures that a particular instance can serve only ONE client at any given point of time. I think it is more to do with applying uniformity to EJBs as a whole, thereby helping container-writers a little.

If I would be replacing a Stateless Session Bean in my application by a Spring-managed POJO, I would certainly go for singleton instance. It will serve equally well if I don't want to maintain client's state.

Best regards,

- Aditya Jha

[Brick Riccardi]

Originally posted by Aditya Jha:

Actually, this is the crux of the problem. Even though one instance would suffice in case of multi-threading, JVM specification ensures that a particular instance can serve only ONE client at any given point of time.
- Aditya Jha

One you say one "Client" what exactly do you mean - do you mean one "thread" ?

Since you mention "Even though one instance would suffice in case of multi-threading" I would think this would pretty much negate the need for a stateless session bean pool assuming you could use Singleton instances?

The only way I see it maybe having some value would be in a case where a single user's thread would try to use more than one instance of a stateless session bean? In real life when would this ever happen (unless maybe by accident of poor design?) OR I guess if you didn't want to use a singleton pojo, a stateless session bean pool could help.

I'm trying to find a concrete example of where a stateless session bean pool helps over using a singleton pojo?

I ask this also from a practical matter since I'll be leveraging EJB3 MDBs in an application and I'm debating whether I should even bother also using stateless session beans for the other beans that my servlet layer might use. Since all the calls will be local I'm wondering if I'm gaining anything by using a stateless session bean as far as performance and scalability go as opposed to using simple singleton pojos (Spring injected?) for this layer.

Thanks for some more clarity on this issue.

[Roger Chung-Wee]

It probably does not make much difference whether or not session beans are pooled on server startup - subject to a sensible upper limit to the maximum number of beans in the pool.

What is far more important is to use EJBs for the purpose they were designed for, like transactions, messaging or distribution.