aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Instance Pooling in Servlets 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 "Instance Pooling in Servlets" Watch "Instance Pooling in Servlets" New topic
Author

Instance Pooling in Servlets

Ajai
Ranch Hand

Joined: May 29, 2002
Posts: 198
Hi All,

I need to design a simple application which will be doing some calculations and displaying the results.I do not have stringent transaction or security requirements,hence I am sticking to vanilla servlets/jsp or struts.
But while going thru the articles on internet
To EJB or Not

I was bit doubtful about my descision since I could not clealy answer the below questions

1. How instance pooling is achieved in Servlet paradigm?
2. What exactly the writer means by container managed persistence in the text below taken from the article

Your system is built faster and more reliably. EJB components benefit from declarative middleware, such as instance pooling, transactions, security, container-managed persistence, container-managed relationships, and data caching


As per my understanding its same as in JDBC ,in CMP we write ejb ql in place of sql? Any specific benefit the container offers in case of EJB for persistence?

Please share your thoughts.

Thanks,
Ajai
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


Any specific benefit the container offers in case of EJB for persistence

None. In my opinion Entity Beans are a very poor choice as a persistance layer. I'll elaborate if you like - though the reasons why they are not a good choice are listed throughout this forum. If you have a search you'll find them. Servlets and some other ORM are a better choice in terms of persistance.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1382
How Entity Beans are a very poor choice as a persistance layer.
Even EJB container provides persistence support to the Entity Beans. It's one of the container provided service.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Is that a question or a statement?
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
This is another good posting that could help you to understand if your organization needs EJB or not: What's it going to take to get you to go with EJB components?.

1. How instance pooling is achieved in Servlet paradigm?

Different container could use different strategies. WebLogic for example creates a pool of servlet instances for each and every servlet that implements SingleThreadModel interface. If the servlet is multithreaded then it will be no reason to pool that instance since client threads can access the servlet instance the way they like (no synchronized code, no delayed answer). The only problem with this approach is that developers must take care of the concurrency access and therefore they must be careful declaring servlet instance variable, using synchronized code and so on.

2. What exactly the writer means by container managed persistence in the text below taken from the article

There is no easy answer for this question Ajai. Paul answer might suggest you that there is no value using entity beans as a persistence layer and I have to disagree with him. This answer could be considered acceptable few ears ago, but in the mean time containers improved a lot and they come up with several out of the box features that look very tempting today. Consider the WebLogic�s ReadOnly concurrency strategy that helps building very fast robust and reliable caching solutions. Clustering is another important issue that offers a lot of benefits to your EJB(s). There are too many container specific features to mention anyway, but I believe you got the picture. The question isn�t to decide whether entity beans are useless or not as a persistence solution, the question is whether learning this entire set of new skills is the best or most appropriate choice or not. Ultimately I�ll let you answer to this question.


I think, therefore I exist -- Rene Descartes
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


container specific features

This is one of the many reasons why not to use Entity Beans. J2EE applications are supported to be portable. I might just be playing Devil's Advocate here, but I'd question the point in learning a technology which I think you are only going to need to support old J2EE apps, rather than one you might actually use to build new ones. Learn them eventually OK, but they should be considered low priority in the range of possibly technologies to get to grips with first.
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704

This is one of the many reasons why not to use Entity Beans.

Then don't use them, that's just fine. ;-)
Regards.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

We'll agree to disagree then.
Ajai
Ranch Hand

Joined: May 29, 2002
Posts: 198
Thanks a lot for sharing your valuable thoughts!

How about using CMP for read only data.
On one hand CMP can prevent database locking and resolve concurrency issues if the read only data is being accessed simultaneously by no. of users.
but on the other hand I read somewhere not to use CMP for read only data(I think because of memory issues) and use session bean with DAO instead.

My question is if I stick to Servlets ,will there be any problem for concurrent access of read only data?
if yes then any alternative other than using session bean+DAO ?

Looking forward to your response.

Thanks.
Phani Kumar
Greenhorn

Joined: Feb 15, 2002
Posts: 22
When you are dealing with just read only data, there is no question of running into concurrency issues. Concurrency issues come up only when two are more users try to change the same data element simultaneously. In my opinion, CMP beans are an overkill for read only data. You can feel the power of CMP only when you go for the advanced features like managing relationships, clustering etc.
 
wood burning stoves
 
subject: Instance Pooling in Servlets