You will find that if you want the _enterprise_ features offered by cmp with
straight jdbc calls, your classes for jdbc calls will be slower than cmp,
and _much more_ difficult to develop.

I am not a smarter developer than Karl or Magnus. Their algorithms for
caching, transaction management, pooling (connection, threads, objects, you
name it), are among the best in the business. If I were to _attempt_ to
reproduce these features, I would certainly _fail_ to reproduce these
features in a reasonable time.

There will always be a place for jdbc in an enterprise application. But in
an enterprise application where the transaction is as important as the data,
and the data structure itself may change from time to time, cmp ejbs are the
way to go.

A resultset relies on datastructure strings, and are closely coupled with
the underlying database structure. All my experience indicates that the
datastructure will change many times during a project, after the project is
finished, and before the application is retired.

jdbc is tightly linked with the datastructure. This link goes to a low
level, as many text strings need to be modified when the datastructure
changes. Arrrrrgh! Don't get caught in the performance trap where you
application performance increases by 2%, but its almost impossible to change
your application without competely rewriting it.


the elephantwalker

-----Original Message-----
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: Saturday, April 06, 2002 10:41 PM
To: Orion-Interest
Subject: RE: [orion-interest]CMP/BMP and standard JDBC, speed is of

> 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
> 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

> So if done right, CMP will be close in speed to straight JDBC, plus
> 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
> 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

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:  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
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
> load
> > one record at a time. With straight JDBC, you can query and get a
> > result set back in one time. When comparing our searching using CMP
> 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
> > JDBC call? Or is it in fact that doing a query with JDBC and getting
> > ResultSet back is much faster than a container that implements CMP?
> > really like to use EJB 2.0 and CMP, but if the results are anything
> > what we are seeing, it seems to be way too slow for big tasks. We
> > re-evaluating if we should use EJB for our tasks or not.
> >
> > Thanks.
> >

Reply via email to