This is a discussion on entity bean (lack of) performance - Java ; I've been comparing performance of my existing app, which is a 3-tier app using Swing and CORBA, to performance using 2 different J2EE designs. In both J2EE cases, I used a browser, JSP and servlets, and session beans running on ...
I've been comparing performance of my existing app, which is a 3-tier
app using Swing and CORBA, to performance using 2 different J2EE
designs.
In both J2EE cases, I used a browser, JSP and servlets, and session
beans running on Weblogic's app server. In one test, I used my own DB
layer; in the other test I used BMP entity beans.
In the case where I wrote my own DB layer, performance was comparable
to my existing app's performance. This was the case for both small and
large queries. Encouraging.
However, when I introduced BMP entity beans, performance degraded,
even with just a couple of hundred rows returned from my query. The
major performance hit is due to the DB query for each row returned
when the app server calls my bean's ejbload method.
The book I've been using as a guide to J2EE, one of the SAM's books,
suggests using either "fast-lane readers" for queries which may return
more than one row, or "fat keys".
The fast-lane reader solution involves doing the DB query directly
from the session bean, pretty much circumventing any DB layer. I don't
like this since it removes the boundary separating my business logic
from my data storage layer. I could use my own DB layer, as my
original solution. But then I lose the scalability and data caching
which the app server provides for me. Two very big selling points of
the J2EE technology are gone.
The fat-key solution involves extending the definition of my primary
key class to include other data in addition to the key data. In this
way, if I get a fat key in my ejbload method, I could just pull the
other data right from the key class itself, rather than again going to
my DB. From a performance standpoint, this worked. But now, if a
non-primary piece of data which I've stuck in my fat key gets changed,
my entity bean clients won't ever see it until the app server decides
to toss out the bean associated with my fat key. Not a very good
solution unless the application is read-only.
At this point, I'm a bit disappointed in BMP entity beans. Am I
missing something? Is there another solution to the performance issue
which would allow me to keep the entity beans? Would CMP entity beans
help? (I haven't gotten to that chapter yet!) At this point, I'm quite
disappointed in the entity bean technology.
Sorry for the long-winded msg. And if you've gotten this far...thanks
for your patience!
AL