• 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

Instance Pooling in Servlets

 
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is that a question or a statement?
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Paul Sturrock
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We'll agree to disagree then.
 
Ajai
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
It's a tiny ad. At least, that's what she said.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic