• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Object pooling

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was on course recently about building layered applications with C#. It was interesting comparing J2EE vs .Net. In the .Net world there doesn't appear to be anything similar to an EJB container. Why is this??

My understanding is the EJB spec doesn't enforce the use of containers. It's just the way vendors chose to implement it. Meaning we could just make api calls directly from our EJB components for these services.

EJB containers provide many services including object pooling. When I asked the instructor about object pooling in .Net. He told me it wasn't necessary as creating and destroying objects is very quick via the garbage collection. He didn't see any scalability problems here. It made me wonder why we bother with object pooling. I suspect back in the old days garbage collection wasn't so great and thats the reason we have this in the EJB spec. Is it still necessary with the advances in garbage collection?? Or am I missing something??
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Aftab Hussain:

EJB containers provide many services including object pooling. When I asked the instructor about object pooling in .Net. He told me it wasn't necessary as creating and destroying objects is very quick via the garbage collection. He didn't see any scalability problems here. It made me wonder why we bother with object pooling. I suspect back in the old days garbage collection wasn't so great and thats the reason we have this in the EJB spec. Is it still necessary with the advances in garbage collection?? Or am I missing something??


Garbage collection has improved immensely since the EJB spec was written. Nowadays there's really no reason to pool objects as in an EJB container.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My understanding is the EJB spec doesn't enforce the use of containers. It's just the way vendors chose to implement it. Meaning we could just make api calls directly from our EJB components for these services.


The EJB spec, which defines the EJB architecture, assumes that the EJB Server Provider and the EJB Container Provider roles are the same vendor. Therefore, it does not architect the interface between the EJB Container and Server, so leaving it up to the vendor how to split the implementation of the required functionality between the EJB Container and Server. However, the spec does define the responsibilities of the EJB Container Provider, namely:

- The deployment tools necessary for the deployment of enterprise beans.
- The runtime support for the deployed enterprise bean instances.

So, API calls should work regardless of which Provider's implementation is used. In short, there must always be a server to provide the implementation of the spec.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

EJB containers provide many services including object pooling. When I asked the instructor about object pooling in .Net. He told me it wasn't necessary as creating and destroying objects is very quick via the garbage collection. He didn't see any scalability problems here. It made me wonder why we bother with object pooling. I suspect back in the old days garbage collection wasn't so great and thats the reason we have this in the EJB spec. Is it still necessary with the advances in garbage collection?? Or am I missing something??


What you are missing is connection pooling as a DBMS runs faster with dedicated connections than if it has to handle incoming connection attempts at run time. Furthermore, depending on the DBMS persistence option, pools may be mandatory so that the server controls the JDBC connection. This ensures your EJB transactions are committed or rolled back correctly and completely.
 
Mattias Arthursson
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Roger Chung-Wee:

What you are missing is connection pooling as a DBMS runs faster with dedicated connections than if it has to handle incoming connection attempts at run time. Furthermore, depending on the DBMS persistence option, pools may be mandatory so that the server controls the JDBC connection. This ensures your EJB transactions are committed or rolled back correctly and completely.


Connection pooling and object pooling is two completely different subjects and should not be confused. Object pooling (as in the EJB world keep a pool of EJB instances alive in order to avoid creating and garbage collecting objects) is virtually useless nowadays, whereas Connection pooling is extremely useful, as you describe above.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The free pool of EJBs improves performance by pre-creating instances, reusing them and skipping container callbacks when it can. If there is little point in such object pooling, then why do EJB vendors provide this facility and explain how to configure pooling in order to tune applications?
 
Mattias Arthursson
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Roger Chung-Wee:
If there is little point in such object pooling, then why do EJB vendors provide this facility and explain how to configure pooling in order to tune applications?


It's all due to historic reasons - in the old days before generational garbage collection it was expensive to recreate and throw away objects. This is no longer an issue. If you don't have any pool of objects there will be no need to tune it.

Also, I suspect some (misguided) fear of threading issues as a reason for the object pooling. Normally, there would be no problem whatsoever in using the same stateless session bean instance over and over, and concurrently between clients, since it's not supposed to hold any state. Compare this to the lightweight design, using e.g. Spring. There you usually have only one instance of the service and dao objects and they are all used concurrently by the clients. As long as the service objects don't have any internal state (which they shouldn't have) this is not a problem.
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am with Mattias on this one...

As mentioned in this thread, the whole purpose of pooling EJB instances was two-fold:
1) To provide better performance since the bean instance wouldn't need to be created on each request.
2) To remove the need for the Bean Provider to write "thread-safe" code... because somehow this was deemed as very difficult.

Number 1 with today's JVMs (or even yesterday's) is a worthless endeavor. In fact, I wonder if the cost of pooling isn't actually HIGHER than the cost of object instantiation for each request.

Number 2 is just a misguided principle. Developers must always consider that their code will be executed in a multi-threaded environment because that knowledge affects all areas of design. The Servlet API is a very good example of this, a SingleThreadedModel option was included from the start that would guarantee no more than one thread was accessing your Servlet instance at a given time. Nearly every Application Server implemented this feature as an object pool of Servlet instances for performance reasons... sound familiar? The funny part is that SingleThreadedModel has always been considered a joke for real application development and the EJB threading model has gone largely unquestioned... yet they are actually one and the same.

Personally, I think the Servlet threading model of one instance for all clients is the best choice to Stateless Session Beans and Message Driven Beans. Obviously Stateful Session Beans and Entity Beans would be implemented differently...
 
Aftab Hussain
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, I want to thank everyone for there post here. It's helped to reinforce my understanding in EJB.

Chris I'm not sure I understand your point here:

>>"Nearly every Application Server implemented this feature as an object >>pool of Servlet instances for performance reasons... sound familiar?

Meaning object pooling of servlets was considered to be faster as it saves time creating and destroying the object back in the good old days. Don't have much experience with servlets, so I can't say it sounds familiar.

>>The funny part is that SingleThreadedModel has always been considered a >>joke for real application development and the EJB threading model has gone >>largely unquestioned... yet they are actually one and the same.

Ok, meaning EJB doesn't support multi-threading and servlets do.

>>Personally, I think the Servlet threading model of one instance for all >>clients is the best choice to Stateless Session Beans and Message Driven >>Beans. Obviously Stateful Session Beans and Entity Beans would be >>implemented differently...

Whats wrong with using the servlet threading model with stateful beans and entity beans?

No one, has answered my question regarding .Net compared to J2EE. Does .Net provide the middleware services we get in the J2EE world??
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chris, I agree with your points...however, I still think we need object pooling in certain scenarios (even though it is not directly related to performance).

In my current assignment, we have a couple of transactions that are very database intensive. We wanted to do these transactions asynchronously at the same time control the concurrency (Obviously, we don�t want 1000 users performing the same operation concurrently and bringing down the database). We use MDB and control the concurrency by limiting the max number of beans in the pool. There might be many other ways to limit the concurrency but to me it looks like maintaining object pool will be the easiest.
 
Ranch Hand
Posts: 8946
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Curious to know whether the vendors still implement object pooling for EJB 3.0?
 
Senthil S Kumar
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, they do. Atleast WebLogic does.
 
author
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just thought I would jump in on this, since I work on OC4J and can give you some insight from an application server engineer.

Bean instance pooling (or object pooling, but that's a pretty generic term) is still a required part of a modern EJB implementation. In order to satisfy the thread-safety requirements of a stateless session bean, each call needs to have its own isolated bean instance for the duration of the call. Although beans are not supposed to hold state between calls, state on the bean is considered safe for the life of the method call. If a bean has no state, you could optimize this away, but generally speaking the only safe way to implement stateless session beans in a high performance way is to use some kind of pooling.

You could create new instances on the fly, but the bean lifecycle methods can add a lot of overhead to the bean creation process. For example, if you have a significant amount of code that executes during ejbCreate or setSessionContext, that code gets executed every single time a bean instance is created. Pooling expensive bean instances is a win here as well.

Cheers,

Merrick
 
Pradeep bhatt
Ranch Hand
Posts: 8946
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

You could create new instances on the fly, but the bean lifecycle methods can add a lot of overhead to the bean creation process. For example, if you have a significant amount of code that executes during ejbCreate or setSessionContext, that code gets executed every single time a bean instance is created. Pooling expensive bean instances is a win here as well.



I am not sure whether we need those complicated life cycle because EJB 3.0 uses POJO and DI.
 
You totally ruined the moon. You're gonna hafta pay for that you know. This tiny ad agrees:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic