• Post Reply Bookmark Topic Watch Topic
  • New Topic

JDBC4Reading Vs EJB  RSS feed

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all:
It is true that for read only with no transactional management operations the use of Entity Beans will increase the overhead (decrease the performance) with no clear benefit, so it is better to use JDBC access encapsuled in the proper DAO and facade patterns? What do you think?
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're about to buy a car with features you'll never be using, you better scale down to a model without those particular features because of their cost overhead. On the other hand, if you don't know whether you'll be needing those features, it would become costly to install them afterwards.
The same forces apply in software development to some degree. Even though a particular feature is not used, you might want to consider taking it for the sake of infrastructure/architecture -- you might need it tomorrow. Now don't take this as a declaration of war against YAGNI; it's not. I'm just saying that it's not always so clear-cut whether a "too" complex solution is a good or a bad thing.
 
Javier Galindo
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Pedro,
yes, it is true that for read only with no transactional management operations the use of Entity Beans will increase the overhead; this is because the Entity Beans life-cycle and the way the container uses transactions.
From Core J2EE Patterns -> Business and Integration Tiers Bad Practices:
"Any Entity bean method is subject to transaction semantics based on its transaction isolation levels specified in the deployment descriptor. Using an an entity bean as a read-only object simply wastes expensive resources and results in unnecessary update transactions to the persistent store. This is due the invocation of the ejbStore() methods by the container during the entity be4an life-cycle. Since the container has no way to knowing if the data was changed during a method invocation, it must assume that it has and invoke the ejbStore() operation. Thus, the container makes no distrinction between read-only and read-write entity beans. However, some containers may provide read-only entity beans, but these are vendor propietary implementations"
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!