wood burning stoves*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Part 2, Fast Lane Reader vs EntityBeans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Part 2, Fast Lane Reader vs EntityBeans" Watch "Part 2, Fast Lane Reader vs EntityBeans" New topic
Author

Part 2, Fast Lane Reader vs EntityBeans

Konstantin Vedernikov
Greenhorn

Joined: Oct 06, 2003
Posts: 6
Hi Folks.

I got serious doubts whether it is good practice to construct two ways to same persistent data: Fast Lane Reader (through DAO) and Entity EJB. First one is used for browsing (no transactions). Second one is used in transactions for order processing. I am not sure if it is good design practice. It is necessary to maintain two different java code for the same persistent data...

Thank you for any thoughts in advance.
Konstantin.
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
I do have doubt about that too but considering the overhead of creating and maintaining entity beans by the container when it is unneccesary if entiy bean is used instead of fast lane reader.
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
IMO, We do need the two ways. For the first one, it is almost a "have to" if you do a search, otherwise the performance will be really bad and you may have some deadlock there. The second way is for coding convenience, if you want to do updating by DAO is OK too, but you need much more efforts but no explict benefits.

Just my two cents.
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
Joseph,
What is IMO?

One of the general practice is not to model read only data as entity bean. What your opinion on modeling on not only read-only data but transactional awareness as an entity bean?
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
It's really more a question of how you're using the data. The Fast Lane Reader is about giving "tabular" access to large quantities of data like for a report. While entity EJB should be about course grained access to one or "relatively" few entities where transactional and security requirements merit the overhead. Not every piece of data should be mapped to an object when it's read from a database. You really need to understand the problem your trying to solve and select appropriate data access strategies based upon those needs. Using a DAO, however, is a good idea so that you program to an interface, reduce couping and make maintenance (...including swapping out back end datasources) alot less painful.


Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Sorry, It's a short for "In My Opinion".
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
I agreed with Byron, he discribed a common practice for using the DAO and EJB ways. One quick question for Byron, why do you think the security is different between the two days? I think the security rules should be the same no matter which way you used.
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
1. I am thinking read-only entity should NOT be modeled as an entity bean even if it involves in transaction. The transaction piece could be managed somewhere else. Again, I am thinking about the overhead of creating and managing entity beans for read-only entity. Commment?

2. What is the pro/con of using DAO vs entity home business bean? Besides what Byron has stated above for DAO, using entity home business bean allows developer to delegate the task of resource management, pooling, security, data source ... to the ejb container.
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
One quick question for Byron, why do you think the security is different between the two days? I think the security rules should be the same no matter which way you used.

EJB provides a specialized security that allows you to programatically or declaratively establish security it also allows you to pass security contexts along between objects. All this capability is provided by the container but it comes with a cost. Functionality like that, even if it's NOT USED, does not come for free. The DAO is a pattern that you choose how to implement, you are free to write as much or as little security as you need within the object or you could delegate it to another object like a factory. If you need the level of security or transaction context of an EJB, then use it....but if all you need is to get data to throw into a report then use up the resources. The really important point in my previous post wasn't related to security it was related to ORM (object relational mapping). ORM mapping is implicit in entity EJB. Data is marshaled in and out of objects to the database (...or other resource). This is fine if you are doing more involved processing within or between enitities, but if you're simply generating a report (...especially if it's of any significant size) you're better off not mapping the data to an object but dealing with the tabular data. Let the database do the heavy work and just spin through the record set or use XSLT to transform the datastream into whatever presentation format you need.
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Hi Byron,

I agreed what you said. On another side, when you look at the J2EE design pattern, both DAO and entity beans are supposed to be used behind session beans(The session facade) and not to expose fine grained business logic to clients(Sets session beans as local affect scalability). So, I think the transaction or security are basically could be handled as the same in session beans.

Vu, if you use entity bean business methods at home class, you have to return a collection of the entity bean objects, that may not what you want(As Byson said, most time we just need tabular data), and DAO helps you to swap DB easilly.
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
Entity home business method can return transfer object (TO). If what you want to query is closely related to the existing entity bean, creating DAO would be unneccesary!
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Hi Vu,

I checked EJB Spec. 2.0 section 9.5.2, but can't find what you mentioned. Where did you get it? Thanks.
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
Use of a Transfer Object is not a part of the specification it's simply another design pattern (...and a good one for many situations)

I don't generally like to use entity beans the way Vu described (no offense). I'd be more apt to provide access through a stateless session bean, but that an architectural choice. I'd also be careful about how heavy weight I made the transfer object. For large amounts of data, depending upon how the transfer object (...most likely an object graph) is structured you could encounter significant overheard in pushing the data from the resultset into the transfer object. Remember the creation of every object instance (...in a composite/object graph) has a cost and the cost is more than the value(s) it holds. It costs in CPU cycles, memory, etc. The creation of a new object is one of the MOST epensive operations in Java. Also all those objects need to be garbage collected. It's the reason why you should ALWAYS do string concatenation with StringBuffer not just slam two string together (i.e. because that creates a third string object to receive the new concatenated value, whereas the append of the StringBuffer does not create additional objects).

Just some stuff to think about...
[ May 10, 2005: Message edited by: Byron Estes ]
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
Joseph,
According to the spec, "home methods are methods that the bean provider supplies for business logic that is not specific to an entity bean instance." I was thinking about querying data and return TO in this method.
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Hi Vu,

For my understanding, the business methods are only finder methods described in section 5.9.2. please correct me if I missed anything.

Constructing TO is costly, but we have no way to avoid it totally right now. My friends told there is a way in EJB 3.0 to "cut" the relationship between entity bean and the DB and then the entity bean becomes TO.
Even if this kind TO is a little more heavy than a regular TO, but we save resources for recreating a complex object, is it true?
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
For my understanding, the business methods are only finder methods described in section 5.9.2. please correct me if I missed anything.


home methods in section 9.5.4 is a business method since spec specifies "An entity EJBHome or EJBLocalHome object provides life cycle operations (create, find, remove) for its entity objects as well as home business methods, which are business methods that are not specific to
an entity bean instance." A business method must return a legal RMI-IIOP type; therefore, returning TO is fine.

Constructing TO is costly, but we have no way to avoid it totally right now.


If you're thinking about a huge response, it is costly. But for small response, it isn't. Besides, TO is needed by both DAO and home business method in order to transfer data to client tier.

My friends told there is a way in EJB 3.0 to "cut" the relationship between entity bean and the DB and then the entity bean becomes TO.
Even if this kind TO is a little more heavy than a regular TO, but we save resources for recreating a complex object, is it true?


I haven't read the early released EJB 3.0, but I agree. It does have overhead on the TO part.
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Hi Vu,

You are right. I mixed the finder methods with the home business methods. Do you know why they put these methods there, it's very similar to session bean methods, just for convenience?
vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 189
I think it is also an efficient resource utilization. Instead of creating a new session bean, just reuse the existing entity bean in the pool.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Part 2, Fast Lane Reader vs EntityBeans