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??
Admit nothing. Blame everyone. Be bitter.
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.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
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??
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
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.
Admit nothing. Blame everyone. Be bitter.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
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?
Admit nothing. Blame everyone. Be bitter.
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.
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
|