aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Why does Stateless Session Beans need pooling? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Why does Stateless Session Beans need pooling?" Watch "Why does Stateless Session Beans need pooling?" New topic
Author

Why does Stateless Session Beans need pooling?

Mauricio Rocha
Greenhorn

Joined: Apr 23, 2008
Posts: 2
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
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30929
    
158

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Kenneth Gustafsson
Ranch Hand

Joined: Jan 10, 2008
Posts: 40
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
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Bill Shirley
Ranch Hand

Joined: Nov 08, 2007
Posts: 457
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


Bill Shirley - bshirley - frazerbilt.com
if (Posts < 30) you.read( JavaRanchFAQ);
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

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
Greenhorn

Joined: Jun 01, 2008
Posts: 22
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
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why does Stateless Session Beans need pooling?