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?
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.
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.
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.
Joined: Feb 17, 2005
This is one of the many reasons why not to use Entity Beans.
Then don't use them, that's just fine. ;-) Regards.
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 ?
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.