RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be java.lang.Object and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;) Does that really work? Can you get access to the value of the key later? I've combed over that part of the spec, but it's terribly vague about how deferred keys are supposed to work. I've never seen a container that documented them, I have never seen an example of them being used, and (until now) I have never known anyone to have tried them. Jeff Schnitzer [EMAIL PROTECTED]
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
Jeff - Yes, it really works. You can get access to the key value later by using getPrimaryKey on the instance. Cheers Ray Jeff Schnitzer [EMAIL PROTECTED] wrote: From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be "java.lang.Object" and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;)Does that really work? Can you get access to the value of the keylater? I've combed over that part of the spec, but it's terribly vagueabout how deferred keys are supposed to work. I've never seen acontainer that documented them, I have never seen an example of thembeing used, and (until now) I have never known anyone to have triedthem! .Jeff Schnitzer[EMAIL PROTECTED]Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
One comment on BMP performance mentioned in this thread. Applying the Fat-Key pattern may allow you to bulk load BMP entities from database with1 query instead of N+1. Tibor -Original Message-From: Ray Harrison [mailto:[EMAIL PROTECTED]]Sent: Tuesday, April 09, 2002 1:30 PMTo: Orion-InterestSubject: RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence Jeff - Yes, it really works. You can get access to the key value later by using getPrimaryKey on the instance. Cheers Ray Jeff Schnitzer [EMAIL PROTECTED] wrote: From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be "java.lang.Object" and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;)Does that really work? Can you get access to the value of the keylater? I've combed over that part of the spec, but it's terribly vagueabout how deferred keys are supposed to work. I've never seen acontainer that documented them, I have never seen an example of thembeing used, and (until now) I have never known anyone to have triedthem! .Jeff Schnitzer[EMAIL PROTECTED] Do You Yahoo!?Yahoo! Tax Center - online filing with TurboTax
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
I probably should have phrased my question a little differently: Is this guaranteed to work on any J2EE-compliant appserver? Jeff -Original Message- From: Ray Harrison [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:30 AM To: Orion-Interest Subject: RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence Jeff - Yes, it really works. You can get access to the key value later by using getPrimaryKey on the instance. Cheers Ray Jeff Schnitzer [EMAIL PROTECTED] wrote: From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be java.lang.Object and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;) Does that really work? Can you get access to the value of the key later? I've combed over that part of the spec, but it's terribly vague about how deferred keys are supposed to work. I've never seen a container that documented them, I have never seen an example of them being used, and (until now) I have never known anyone to have tried them! . Jeff Schnitzer [EMAIL PROTECTED] _ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax
Re: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
On Sun, Apr 07, 2002 at 01:11:37PM -0700, Jeff Schnitzer wrote: Irrespective of who may be a smarter developer, I can guarantee you that I know a *lot* more about *my* specific business logic than Karl or Magnus. Furthermore, Karl and Magnus are for the most part just implementing a specification produced by a committee of labcoats dedicated to a lowest-common-denominator set of features that IBM, BEA, Borland, Sybase, the rest of the implementers can agree to. The absence of ORDER BY in EJB-QL and the lack of a standard PK generation mechanism make me seriously wonder if any of the people writing the EJB spec have ever used it to implement a real-world application. Forgive me, but what about the case where you just set the prim-key-class to be java.lang.Object and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;) Cheers, Simon -- Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room.
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
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. Argh! 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. regards, the elephantwalker www.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [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 essence 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
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
From: The elephantwalker [mailto:[EMAIL PROTECTED]] 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. Eh? Connection pooling and transaction management are provided to session beans through the data source. No CMP or entity beans necessary. Furthermore, if you want sane transaction demarcation, you already have to wrap all your entity bean access in session bean methods. Entity bean caching I have found to be remarkably useless. First of all, it depends on a pessimistic locking strategy, which is both hard to use (gotta love those deadlock exceptions!) and not applicable to a clustered environment or any environment in which the database table can be modified from an external source. Furthermore, finder methods are not cached - and with an eager loading strategy, I really have to wonder what the great advantage of the caching is... bringing all the bean data back usually isn't that much more expensive than bringing just the PK data back, and if it is (because of large data fields) then your cache is going to have size problems anyways. Irrespective of who may be a smarter developer, I can guarantee you that I know a *lot* more about *my* specific business logic than Karl or Magnus. Furthermore, Karl and Magnus are for the most part just implementing a specification produced by a committee of labcoats dedicated to a lowest-common-denominator set of features that IBM, BEA, Borland, Sybase, the rest of the implementers can agree to. The absence of ORDER BY in EJB-QL and the lack of a standard PK generation mechanism make me seriously wonder if any of the people writing the EJB spec have ever used it to implement a real-world application. 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. Entity beans can be useful for modeling your data. For some business cases, they might actually be all you need. I, however, have yet to see one of those cases in the real world. I will reiterate the three failings I mentioned before: you cannot model relationship attributes, you cannot perform aggregation queries, and you cannot query for data that spans multiple objects. I'll add that if you're restricting yourself to EJB-QL, you're going to have even bigger problems, like the inability to order the result set without sorting yourself in Java. Relational databases have evolved over the last thirty years to provide us with a very refined solution for storing and accessing enterprise data. Entity beans are a big square peg that can only be brutally forced into the multifaceted hole that is our problem space. 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. Argh! 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. If the primary argument for using entity beans is that they offer a layer of indirection so that you can rename columns, there are plenty of alternative approaches which are *much* simpler. I'm not saying don't use entity beans (although I would *definitely* recommend that a team which does not already have a lot of EJB expertise should avoid them), but I am saying that it is a huge mistake to consider entity beans your only means of data access. To use the square peg analogy again, reduce the size of the square to something that fits smoothly through the hole, and fill in around the edges with other mechanisms (like JDBC). Jeff Schnitzer [EMAIL PROTECTED] Consulting Contracting - J2EE, WebLogic, Orion/OC4J
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
Entity bean caching I have found to be remarkably useless. First of all, it depends on a pessimistic locking strategy, which is both hard to use (gotta love those deadlock exceptions!) and not applicable to a clustered environment or any environment in which the database table can be modified from an external source. Furthermore, finder methods are not cached - and with an eager loading strategy, I really have to wonder what the great advantage of the caching is... bringing all the bean data back usually isn't that much more expensive than bringing just the PK data back, and if it is (because of large data fields) then your cache is going to have size problems anyways. The latest oc4j release has four different load-locking strategies to choose from, and you can be sure these will make it into Orion. pessimistic, old-pessimistic, optimistic, and read-only. There are also stategies for timing out instances for ejb's. Irrespective of who may be a smarter developer, I can guarantee you that I know a *lot* more about *my* specific business logic than Karl or Magnus. Furthermore, Karl and Magnus are for the most part just implementing a specification produced by a committee of labcoats dedicated to a lowest-common-denominator set of features that IBM, BEA, Borland, Sybase, the rest of the implementers can agree to. The absence of ORDER BY in EJB-QL and the lack of a standard PK generation mechanism make me seriously wonder if any of the people writing the EJB spec have ever used it to implement a real-world application. I believe they are also on some of these committees. They have also implemented a far better finder language than ejb-ql, and you can use ORDER BY in the orion-ejb-jar.xml. Brett McLaughlin has published a truely excellent strategy for producing pk's. Go to flashline.com to see Brett's column on this. regards, the elephantwalker www.elephantwalker.com
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. 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! 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.
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
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.
