Re: EJB find methods. Why do they return only the primary key?

From: Sudsy (bitbucket44_at_hotmail.com)
Date: 11/23/04 

Date: Mon, 22 Nov 2004 23:28:45 -0500

Doug Pardee wrote:
<snip>

Thank you for a most eloquent description.

> Entity beans are designed to always behave correctly under all
> conditions. They are inherently low-performance and should be
> approached carefully in any system that is expected to be under heavy
> load. In addition to the 'n+1' problem (which can sometimes be
> circumvented with some containers), you have scalability challenges
> introduced by the limitation that only one client can be accessing an
> entity bean at a time. Entity beans must be accessed inside
> transactions, which generally is inappropriate for OLAP applications.
> And depending on your database, you might end up with unnecessary lock
> escalation which can further damage scalability.

I agreed with everything you said, save this last paragraph. In cases
where there is a lot of contention for table (or view) rows, CMP entity
EJBs can actually improve performance.
Well-designed implementations draw on the experience gained through
many years and iterations and access methods which provide the best
performance with minimal contention.
I'd be the first to agree that the initial attempts in this area fell
far short of potential. You only have to look at the ommission of the
ORDER BY clause in the initial implementation of EJB-QL to see that
they didn't offer what many consider to be essential functionality
at the beginning. Things have improved considerably since then.
I still believe that CMP entity EJBs (especially when you utilize
CMR) provide flexibility and power as a component of an enterprise
application.
And I also believe that many of the performance limitations are behind
us. Now if someone wants to fund a research project to prove that
premise... ;-) 

-- 
Java/J2EE/JSP/Struts/Tiles/C/UNIX consulting and remote development.