• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What is the benefit of pooling ejb instances?

 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anyone know what is the real benefit from pooling ejb instances?
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    What a stench! Central nervous system shutting down. Save yourself tiny ad!
    a bit of art, as a gift, the permaculture playing cards
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic