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