aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes What is the benefit of pooling ejb instances? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "What is the benefit of pooling ejb instances?" Watch "What is the benefit of pooling ejb instances?" New topic
Author

What is the benefit of pooling ejb instances?

Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Does anyone know what is the real benefit from pooling ejb instances?


I think, therefore I exist -- Rene Descartes
Arun
Ranch Hand

Joined: Oct 03, 2003
Posts: 40
In the context of stateless session beans it saves the overhead involved in creating and destroying beans. Just the same benefits you get from using a connection pool in jdbc. If you think that is not a real benefit elaborate on your thoughts...

Cheers!
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi linoops,

Thank you for your answer.
Well this is what I thought for a while. But right now I�m little bit older and I start doubting those benefits. I seriously doubt that ther is any overhead involved in creating ejb instances and to compare this with jdbc connections is not the best example. To create a connection is a very costly operation. It might take probably 100-200ms, depending upon many factors like network, whether the container tests the connection, etc. However building an empty ejb instance will always take about � 0ms. Probably not the way the container creates them today, using reflection and the Class.newInstance call, but just calling the appropriate constructor.
As for destroying those instances I�m neither very sure what�s the benefit either. Java is very mature and provides several garbage collector algorithms that are very performant. Hence allowing java to handle both construction/destruction of the ejbs instances looks to me like a very good choice as well.
I think what I�m suggesting is this: allow clients to create ejb instances on demand and let the garbage collector destroy them like any other java objects.
Still believe that instance pooling brings that much?
Arun
Ranch Hand

Joined: Oct 03, 2003
Posts: 40
Valentin,
You probably are correct in saying that comparng with jdbc connections is not the best example. hmm.. I am not sure I have an answer, but here is a thought; we are assuming that the create and destroy are simple methods. What if a stateless session bean reads a bunch of initialization parameters from the database during it's create(list of states and their tax percentges for example)?
In an application with say a 1000 clients connected to the system, would it not be better to have say 50 instances of beans rather than 1000 instances and going through a cleanup process every now n then?

I am not sure these are convincing replies, guess i need to grow old a lil , nice post though.

Cheers!
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Thank you again for your reply.
Well let me tell you what I believe about this instance pooling. Let�s say one defines an entity ejb and maps it to the right table. When the container decides to create more instances in the pool, the container will create new objects of that type having blank or null attributes. I�m pretty sure that no much initialization is done at this time, except maybe instantiating the attributes with their corresponding java types (but I guess not). However this will imply that 100 new objects are created, which will happen very fast. After the client runs a finder (which uses a instance from pool), gets the remote interface and starts running business methods, the container loads the data from the database, gets an instance from the pool and fills its attributes with the right values. Because this is a very costly operation containers will probably choose to cache this heavy weight beans (at least this is what weblogic does). Again pooling instances doesn�t buy much here.
As for having a less number of instances, serving a larger number of clients I�m not very convinced either. Sure the container might save some memory here but will delay clients if no instances are available. Finally people like thinking like this: if 1000 users are connected then 1000 threads spans the container. Well this is not very true because of two reasons:
  • The container maintains several pools of execution threads, which doesn�t usually exceed 25-30 threads. Hence not more than 30 threads could run concurrently, no matter how many clients are connected.
  • The jvm itself has a setting that limits the number of execution threads as well. Usually a value greater than 70 will make it contra-roductive.


  • Regards.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: What is the benefit of pooling ejb instances?