From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 06, 2002 6:20 PM
To: Orion-Interest
Subject: Re: [orion-interest]CMP/BMP and standard JDBC, speed is of
essence
CMP will load in all the entities in one go (in orion at least).
There will be a performance difference between straight JDBC and EJB,
since
there's more involved with an EJB query. Transactions, constructing
entities
and so on are extra overhead that just getting a resultset back will
not
have.
If you use JDBC from a connection obtained from a DataSource in a
Session bean, all queries should have the transaction attributed defined
for the Session bean method. You do not need entity beans to have
transactions.
So if done right, CMP will be close in speed to straight JDBC, plus
you
have
the potential for more goodies like container caching of finders and
entities and so on, that you'd get for 'free' in some new version of
your
favourite container, if it doesn't do so already!
There's that if done right problem.
If Orion (or any other app server) backed the Collection returned by a
finder with the ResultSet itself (instead of producing ArrayLists), then
it seems like performance wouldn't be too much different from JDBC. Of
course, you're going to have all the overhead of constructing entity
bean objects and loading them with all the data (ok, maybe part of the
data if you're using WebLogic or other container with field groups), but
it shouldn't be too dramatic compared to the remote database call.
I don't know if there is a technical problem with doing this or if other
containers do this, but Orion doesn't seem to be that smart. So yeah,
entities are going to be slower, especially if you're listing 1000's of
them.
EJB-QL, even if Orion supported it, is only going to make things worse.
It's an abstraction above SQL. All the hints and other
database-specific goodies that you can normally encode in a SQL
statement cannot be used. And you can't order the result set with EJB
QL, so sorting has to be done outside the database (yeah, right!).
I have found that a good approach to data access is to model your data
using CMP entity beans, use them for write access, and code in JDBC
whenever you need listing behavior that CMP is too slow or too
inflexible to support.
By far the biggest problem is that too inflexible part, IMHO...
modeling relationship attributes, performing aggregation queries, or
querying for data that spans multiple objects simply does not fit into
the world of entity beans. This criticism seems to apply to just about
any O/R mapping scheme... which is why I think they are useful, but
should not be taken too seriously.
A good example of this hybrid approach is the Punk Image Gallery
sample application for the Maverick MVC framework:
http://mav.sourceforge.net/pig. It is a comprehensive sample J2EE
application which runs on Orion. It's not a trivial sample; my friends
and I actually use a live instance to archive (and annotate, wiki-like)
our images. There is *no* way it could perform reasonably with pure
entity beans.
Jeff Schnitzer
[EMAIL PROTECTED]
Consulting Contracting - J2EE, WebLogic, Orion/OC4J
On 6/4/02 7:15 pm, Duffey, Kevin [EMAIL PROTECTED] wrote:
Hi all,
Kinda curious about one thing. We use BMP, and tried CMP. Both seem
to
load
one record at a time. With straight JDBC, you can query and get a
large
result set back in one time. When comparing our searching using CMP
and
BMP,
it is over 100 times slower than a straight JDBC query when getting
several
1000 records. Maybe we are doing something wrong, but can anyone
tell me
if
this makes sense? Should CMP with EJB 2.0 (and lets use all aspects,
such as
the EJB QL language if necessary to do a query) be as fast as a
straight
JDBC call? Or is it in fact that doing a query with JDBC and getting
the
ResultSet back is much faster than a container that implements CMP?
Id
really like to use EJB 2.0 and CMP, but if the results are anything
like
what we are seeing, it seems to be way too slow for big tasks. We
are
re-evaluating if we should use EJB for our tasks or not.
Thanks.
