Re: [JBoss-user] Cmp vs hibernate
söndagen den 12 januari 2003 kl 01.54 skrev Pete Beck: Why not, it would be much more efficient? I am somewhat misquoting You above ... to stress ... that of course there could be another acronym ... but RDBMS/OODBMS ... --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
On Fri, 2003-01-10 at 22:44, Schnitzer, Jeff wrote: > > Which is probably why no-one has developed a commercial solution for > the > > problem. > > Eh? What was Gemstone/J? I have no idea. It is not a product that I am familiar with. But if it is as you suggest, a native CMP store such as the one I was describing, I'd be grateful if you could post a URL with more information as it might be something (as I have mentioned elsewhere) that I might be interested in. I had a look on their site and the only thing I could find was their CMP accelerator, which still seems to use an underlying RDBMS and doesn't seem to be what I was talking about. > RDBMSes (and the myriad tools surrounding them) have evolved under > real-world pressures over the last 30+ years. The concept (and a > half-dozen different implementations) are about as refined as enterprise > software gets. It will be a long time before it has been proven "safe" > to store mission-critical data anywhere else. I have to disagree here. RDBMS technology is mature and been around for 30 years but that doesn't mean anything. C has been around for longer but would you suggest that we write all of our new code in C? Many seem to be confident programming in Java, C# or C++ which if you like are the "next generation" of C. Why should databases be any different? Postgres is based on RDBMS principles, but also contains many object oriented features. In fact the authors call it an Object Relational database management system. It is arguable that the reason why we have EJB and hibernate in the first place is because RDBMSes have not evolved sufficiently enough. Many of the concepts in J2EE have been around for 30+ years as well but J2EE itself is very new and still growing. That hasn't prevented it from becoming a market leading enterprise technology. I will agree partially with your last point about data safety. There isn't a lot out there as an alternative to RDBMS (which I believe is what I was saying anyway) but is that because it is technically not possible? I doubt it. > IMHO, trying to create a general-purpose persistence mechanism that > abstracts both RDBMS and ODBMS data stores is foolish. Why would you need to do this anyway? I was suggesting that CMP data is stored natively (i.e. no abstraction) and RDBMS functionality is provided through an emulation layer. If your database is to be used primarily as a CMP store, why not optimise it for that job and provide emulated relational access as a "legacy" layer? This would be no different from an O/R mapped system, except it might be considered R/O mapped - the roles are reversed. > One of the > really frustrating things about EJB CMP (before I ditched it in favor of > Hibernate, one of the best decisions I ever made) was how difficult CMP > made it to sidestep the abstraction and use aggregation queries, outer > joins, and other performance-enhancing techniques. I will agree that there are some things which are a pain (if not impossible) to do in CMP. The biggest problem I see with the abstraction is performing efficient operations on large blocks of data, such as bulk updates, deletes or reports. This is probably similar to your complaint. This is a tough problem I suspect. It should be possible to create an API that will do the job, but this would leave you in the cold for BMP entities. There is a also a lack of run-time functionality; consider the possibility of having runtime defined finder functionality for example. Hibernate has some nice features in this area. I also like the fine control that you have over database locks (is there away of making "read-only" finders in JBoss?). However CMP beans do more than just persistance, they also have per-method transactional and security control for one thing, not to mention remote interfaces etc. Hibernate cannot therefore be viewed as a drop-in replacement for CMP in all cases. > If you are writing code and thinking to yourself "hey, maybe I'll move > my datastore to an ODBMS sometime in the future" then you're writing a > toy, not a serious enterprise application. In the real world that > doesn't happen. It's tough (organizationally and technically) just to > switch database vendors. I hold my hand up and confess here, I build toys where future reconfiguration and different deployment environments are taken into account. This is why I like to use abstraction layers so that I can change database, J2EE container (or maybe just parts of it) without having to rewrite my 600+ classes. I note that SAP and Siebel like to have similar abstractions in their toys. If I had the luxury of knowing that my database would always be the same, my hardware platform and OS always the same, then I probably wouldn't use J2EE at all. I'd probably use C++, and write database code using native libraries. Why not, it would be much more efficient? -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electr
Re: [JBoss-user] Cmp vs hibernate
On Friday, January 10, 2003, at 04:44 PM, Schnitzer, Jeff wrote: IMHO, trying to create a general-purpose persistence mechanism that abstracts both RDBMS and ODBMS data stores is foolish. One of the Jeff, I couldn't disagree with you more. To attract RDBMS guys you need to support RDBMS databases on the back end and full query language on the front. To attract ODBMS guys you really need transparent persistence (something like JDO) and you need fast relational navigation. Both of these can be accomplished in the same system. Think of something like JDO with a well written object cache. There are some real tricks to the implementation but they can be overcome. IMO the reason we don't have this type of system today is the RDBMS guys don't care about the object guys and the ODBMS guys are in marc's words "wee-wee touching OO guys". Remember at the end of the day all the data is stored in a sequence of bytes in a spiral configuration on a metal(ish) platter. really frustrating things about EJB CMP (before I ditched it in favor of Hibernate, one of the best decisions I ever made) was how difficult CMP made it to sidestep the abstraction and use aggregation queries, outer joins, and other performance-enhancing techniques. That is an implementation issue and does not support your first claim. A vendor such as jboss could support better out of band queries, and we plan on for 4.0. If you are writing code and thinking to yourself "hey, maybe I'll move my datastore to an ODBMS sometime in the future" then you're writing a toy, not a serious enterprise application. In the real world that doesn't happen. It's tough (organizationally and technically) just to switch database vendors. Now I totally agree here. I think the bigger issue is an ODBMS has completely different performance characteristics then an RDBMS, and you end up developing to these characteristics. For example, ODBMSes excels at in memory relational navigation, and RDBMSes suck at this. If you are using an RDBMS it is much better to jump to a location in the object graph using a query. The difference between performance of these systems can be reduced with good caching and read-ahead logic, but most do not code this. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
> From: Pete Beck [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 10, 2003 12:36 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Cmp vs hibernate > > On Thu, 2003-01-09 at 19:32, Dan Christopherson wrote: > > Probably the second biggest thing (after fear of change) that caused > > ODBMS's to be stillborn: "Will > tool> work with it? No!?!?! How do you expect to sell it?" > > Which is probably why no-one has developed a commercial solution for the > problem. Eh? What was Gemstone/J? RDBMSes (and the myriad tools surrounding them) have evolved under real-world pressures over the last 30+ years. The concept (and a half-dozen different implementations) are about as refined as enterprise software gets. It will be a long time before it has been proven "safe" to store mission-critical data anywhere else. IMHO, trying to create a general-purpose persistence mechanism that abstracts both RDBMS and ODBMS data stores is foolish. One of the really frustrating things about EJB CMP (before I ditched it in favor of Hibernate, one of the best decisions I ever made) was how difficult CMP made it to sidestep the abstraction and use aggregation queries, outer joins, and other performance-enhancing techniques. If you are writing code and thinking to yourself "hey, maybe I'll move my datastore to an ODBMS sometime in the future" then you're writing a toy, not a serious enterprise application. In the real world that doesn't happen. It's tough (organizationally and technically) just to switch database vendors. Jeff Schnitzer --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Cmp vs hibernate
On Thu, 2003-01-09 at 19:32, Dan Christopherson wrote: > Probably the second biggest thing (after fear of change) that caused > ODBMS's to be stillborn: "Will tool> work with it? No!?!?! How do you expect to sell it?" Which is probably why no-one has developed a commercial solution for the problem. But you are also forgetting the political pressure of the hoards of Oracle guys, who have been doing Oracle for 100 years who will tell you that anything that isn't Oracle (that might mean they have to learn something new) is evil. :-) If we are interested in technical merits rather than commercial merits (as most open source software is) then ODBMS probably has the edge over RDBMS for Java work. Likewise a native CMP store would be the ultimate for EJB, providing that it came with the same sort of features that you would expect from a modern RDBMS (e.g. a shell, backup, monitoring etc.). Your point regarding ODBMS is a good one, - having a lack of standard tools and standards has definitely been a bar. However CMP doesn't suffer from the same problem because switching the CMP implementation (from say O/R mapping to native) doesn't require changes to the application code (in theory). You could even provide a SQL/JDBC interface to your CMP store to support legacy applications such as reporting tools. i.e. the relational interface is emulated, not the CMP interface. As I mentioned earlier, such a database would be ideal for my app (I don't need legacy support) and I bet there are lot of others in the same situation. -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Cmp vs hibernate
Their performance was pretty good in what it was optimized for: navigational access. Query performance was horrendous. This is somewhat the mirror image of relational database at the same level of maturity: they were great for queries, but navigational access sucked. -danch Eric Kaplan wrote: Maybe things have changed recently, but I think the biggest thing against them (besides some of their obscene pricing policies - read ObjectStore) was their poor performance querying across very large sets of data compared to their stodgy relational counterparts. They were stillborn because they fell apart under certain conditions. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Christopherson Sent: Thursday, January 09, 2003 2:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Cmp vs hibernate Matthew Baird wrote: couple notes: - try selling an enterprise level application that doesn't support a "standard" rdbms on the backend (oracle/sql server/db2) Probably the second biggest thing (after fear of change) that caused ODBMS's to be stillborn: "Will work with it? No!?!?! How do you expect to sell it?" -danch --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
Maybe things have changed recently, but I think the biggest thing against them (besides some of their obscene pricing policies - read ObjectStore) was their poor performance querying across very large sets of data compared to their stodgy relational counterparts. They were stillborn because they fell apart under certain conditions. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Christopherson Sent: Thursday, January 09, 2003 2:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Cmp vs hibernate Matthew Baird wrote: > couple notes: > > - try selling an enterprise level application that doesn't support > a "standard" rdbms on the backend (oracle/sql server/db2) Probably the second biggest thing (after fear of change) that caused ODBMS's to be stillborn: "Will work with it? No!?!?! How do you expect to sell it?" -danch --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Cmp vs hibernate
Matthew Baird wrote: couple notes: - try selling an enterprise level application that doesn't support a "standard" rdbms on the backend (oracle/sql server/db2) Probably the second biggest thing (after fear of change) that caused ODBMS's to be stillborn: "Will work with it? No!?!?! How do you expect to sell it?" -danch --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
couple notes: - try selling an enterprise level application that doesn't support a "standard" rdbms on the backend (oracle/sql server/db2) - many O/R frameworks were designed with alternative stores in mind (LDAP, Object db, Prevayler (http://sourceforge.net/projects/prevayler)) - CMP implemented as flat files or XML sounds slower than a rdbms to me for non-trivial applications - SQL usually goes through a layer before it gets executed (JDBC, ODBC), Direct SQL execution via native libraries is still a "layer" that includes transport; SQL will still be compiled on the db server at runtime in most cases. - anytime you have a query language, you pay for the compile/binding steps, be that SQL, OQL, or EJBQL. The only thing you can do is limit the amount of compiling you have, which also minimizes your portability (ie EJBQL -> SQL ) if you can get away without using a RDBMS, that's great you can probably make a pretty quick application, but as soon as you need functionality like searching, sorting, aggregate operators, transactions, etc it starts to look (and smell) more and more like a db. just my $0.02 > Your code -> datastore That's an easy one. SQL is more or less an example of this. The code you write in SQL interacts directly with the datastore (ignoring transport and compilation issues). Similarly, I could see a technology where CMP takes the place of SQL and the concept of rows and tables vanishes completely. CMP would probably even have the edge over SQL, because most of the queries (finders and friends) could be compiled at deployment time whereas SQL is generally compiled on the fly. Additionally, indices could be automatically calculated. Getting back to the subject of the thread, I would say that in performance terms it seems likely that light-weight persistent object frameworks will out match CMP frameworks doing O/R mappings. However this is not a limitation of CMP, only the current implementations of it. It should be possible to have a CMP implementation that can outperform even raw JDBC. Writing a CMP application will give you the option of being able to upgrade it to more advanced technology later without code changes. A reliable, transactional, clusterable, native CMP store would rock. If it came with some supporting tools (such as a shell for doing ad-hoc operations) then it would eliminate the need for a relational database at all in many applications (including mine). -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
On Thu, 2003-01-09 at 14:02, Matthew Baird wrote: > so you are promoting using what? No promotion I am afraid, merely an observation. Comparing CMP with persistent object frameworks is not really a fair comparison. Comparisons are odourous as Shakespeare once wrote. :-) In my mind, it is like comparing Macromedia Flash with HTML. Similar results can be achieved with both technologies, but their design philosophies are totally different. The confusion is that people assume CMP must map to a relational database through JDBC. This is not the case, CMP was designed to be an abstract concept handled by the EJB container. The confusion has no doubt been increased by the fact that relational mappings are by far the most common way of doing CMP. CMP could be implemented using flat files, or an XML file as other examples. I believe I read somewhere that JBoss 4.0 will make it much easier to have different CMP implementations. > Do you have an example of: > > Your code -> datastore That's an easy one. SQL is more or less an example of this. The code you write in SQL interacts directly with the datastore (ignoring transport and compilation issues). Similarly, I could see a technology where CMP takes the place of SQL and the concept of rows and tables vanishes completely. CMP would probably even have the edge over SQL, because most of the queries (finders and friends) could be compiled at deployment time whereas SQL is generally compiled on the fly. Additionally, indices could be automatically calculated. Getting back to the subject of the thread, I would say that in performance terms it seems likely that light-weight persistent object frameworks will out match CMP frameworks doing O/R mappings. However this is not a limitation of CMP, only the current implementations of it. It should be possible to have a CMP implementation that can outperform even raw JDBC. Writing a CMP application will give you the option of being able to upgrade it to more advanced technology later without code changes. A reliable, transactional, clusterable, native CMP store would rock. If it came with some supporting tools (such as a shell for doing ad-hoc operations) then it would eliminate the need for a relational database at all in many applications (including mine). -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
so you are promoting using what? Do you have an example of: Your code -> datastore thanks, Matthew -Original Message- From: Pete Beck [mailto:[EMAIL PROTECTED]] Sent: Thu 1/9/2003 1:35 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-user] Cmp vs hibernate On Wed, 2003-01-08 at 22:45, Matthew Baird wrote: > I disagree with your statement of > "Let's face it, O/R mappings will never be very efficient. " > > Both OJB (to which I contribute) and Hibernate (which I watch closely) > approximate raw JDBC performance in most cases, and can exceed it in many others. > Go check out the performance target in OJB, and Hibernate documentation > goes over performance extensively. Both are GREAT projects, but neither is CMP. Yes, but here you are making the assumption that JDBC is efficient, which it isn't. JDBC is an abstraction layer itself, as it the SQL (which must generally be parsed and compiled) that it executes. If you think about the big picture, you will notice how much extra work is being done just to make the relational model fit the object model. O/R mapping layers: Your code -> O/R mapping layer -> JDBC -> SQL -> datastore. That's quite a lot of repackaging before you finally access the information in the database. The above will *never* be as efficient as this: Your code -> datastore. But even this could be an improvement: Your code -> CMP layer -> datastore. Additionally, relational databases are usually separate processes, so JDBC also loses out because of the IPC/RPC and the marshalling and unmarshalling of data. Performance would be dramatically improved if the datastore was in the same process and had a minimal amount of marshalling to do. -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user <>
RE: [JBoss-user] Cmp vs hibernate
On Wed, 2003-01-08 at 22:45, Matthew Baird wrote: > I disagree with your statement of > "Let's face it, O/R mappings will never be very efficient. " > > Both OJB (to which I contribute) and Hibernate (which I watch closely) > approximate raw JDBC performance in most cases, and can exceed it in many others. > Go check out the performance target in OJB, and Hibernate documentation > goes over performance extensively. Both are GREAT projects, but neither is CMP. Yes, but here you are making the assumption that JDBC is efficient, which it isn't. JDBC is an abstraction layer itself, as it the SQL (which must generally be parsed and compiled) that it executes. If you think about the big picture, you will notice how much extra work is being done just to make the relational model fit the object model. O/R mapping layers: Your code -> O/R mapping layer -> JDBC -> SQL -> datastore. That's quite a lot of repackaging before you finally access the information in the database. The above will *never* be as efficient as this: Your code -> datastore. But even this could be an improvement: Your code -> CMP layer -> datastore. Additionally, relational databases are usually separate processes, so JDBC also loses out because of the IPC/RPC and the marshalling and unmarshalling of data. Performance would be dramatically improved if the datastore was in the same process and had a minimal amount of marshalling to do. -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
I disagree with your statement of "Let's face it, O/R mappings will never be very efficient. " Both OJB (to which I contribute) and Hibernate (which I watch closely) approximate raw JDBC performance in most cases, and can exceed it in many others. Go check out the performance target in OJB, and Hibernate documentation goes over performance extensively. Both are GREAT projects, but neither is CMP. cheers, Matthew -Original Message- From: Pete Beck [mailto:[EMAIL PROTECTED]] Sent: Wed 1/8/2003 12:04 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-user] Cmp vs hibernate A common usage for CMP entity beans seems to be for persistent objects using an O/R mapping. Although entity beans can generally act that way, that is by no means all they amount to. In fact Sun have a more light-weight spec for this purpose (JDO). I can't help feeling that hybernate is nearer to JDO than to EJB. IMHO, CMP beans are more like abstract components (or black boxes if you like) than persistent objects. This is why they have all the interfaces. They were designed to be accessed over RMI and act more as service providers than as discrete objects. An entity bean abstraction can be very complex and span many objects. The are designed to be scalable so that if they are very complex, they do not need to reside permanently in memory although give their clients the illusion that they are. Of course, these principles were developed when memory was a lot more of a problem than it is today. The CMP part is actually an implementation detail and the O/R mapping even more so. Hence performance issues can never be blamed on CMP, but rather on their implementations. Let's face it, O/R mappings will never be very efficient. For CMP to realise its full potential there needs to be a new feature rich database technology developed that is optimised specifically for EJB, and provides CMP functionality natively. In fact that sounds like it would be a pretty cool project. :-) On Wed, 2003-01-08 at 18:24, [EMAIL PROTECTED] wrote: > We are missing support for SUM and COUNT sql-function as well as > subqueries in CMP, which hibernate have. This has forced us into using > pure sql for this part to get it reasonable fast. > > Also you don't need all dataobjects and interfaces in hibernate, so we > should try it soon, nut it would be nice too see a performance comparison with CMP, hibernate, JDO and OJB. We are not satisfied with whe performance of CMP and only pure SQL had probably have been faster (although jboss is supposed to have cache). -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user <>
Re: [JBoss-user] Cmp vs hibernate
A common usage for CMP entity beans seems to be for persistent objects using an O/R mapping. Although entity beans can generally act that way, that is by no means all they amount to. In fact Sun have a more light-weight spec for this purpose (JDO). I can't help feeling that hybernate is nearer to JDO than to EJB. IMHO, CMP beans are more like abstract components (or black boxes if you like) than persistent objects. This is why they have all the interfaces. They were designed to be accessed over RMI and act more as service providers than as discrete objects. An entity bean abstraction can be very complex and span many objects. The are designed to be scalable so that if they are very complex, they do not need to reside permanently in memory although give their clients the illusion that they are. Of course, these principles were developed when memory was a lot more of a problem than it is today. The CMP part is actually an implementation detail and the O/R mapping even more so. Hence performance issues can never be blamed on CMP, but rather on their implementations. Let's face it, O/R mappings will never be very efficient. For CMP to realise its full potential there needs to be a new feature rich database technology developed that is optimised specifically for EJB, and provides CMP functionality natively. In fact that sounds like it would be a pretty cool project. :-) On Wed, 2003-01-08 at 18:24, [EMAIL PROTECTED] wrote: > We are missing support for SUM and COUNT sql-function as well as > subqueries in CMP, which hibernate have. This has forced us into using > pure sql for this part to get it reasonable fast. > > Also you don't need all dataobjects and interfaces in hibernate, so we > should try it soon, nut it would be nice too see a performance comparison with CMP, >hibernate, JDO and OJB. We are not satisfied with whe performance of CMP and only >pure SQL had probably have been faster (although jboss is supposed to have cache). -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
Why would you want to use hsqldb? Its not transactional. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, January 08, 2003 12:57 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Cmp vs hibernate > > > > onsdagen den 8 januari 2003 kl 17.23 skrev Bill Burke: > > > Will hibernate provide you with a distributed clustered cache solution? > > JBoss 4.0 CMP will. > > If You are using hsqldbr(eplikated) - it probably would ... > > *hsqldbr(eplicated) > http://www.javagroups.com/javagroupsnew/docs/hsqldbr/design.htm > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Cmp vs hibernate
We are missing support for SUM and COUNT sql-function as well as subqueries in CMP, which hibernate have. This has forced us into using pure sql for this part to get it reasonable fast. Also you don't need all dataobjects and interfaces in hibernate, so we should try it soon, nut it would be nice too see a performance comparison with CMP, hibernate, JDO and OJB. We are not satisfied with whe performance of CMP and only pure SQL had probably have been faster (although jboss is supposed to have cache). -- Marius Kotsbak Boost communications AS www.boostcom.no On Wed, Jan 08, 2003 at 09:03:12AM -0500, LaBanca, Rick wrote: > > A bit off topic, but I need to ask those who have explored... > > Has anyone here used hibernate in preference to cmp? If so how has it worked > out for you in jboss? We are considering it or cmp. Hibernate certainly > seems more flexible, but I was thinking it doesn't abstract the app from the > data as much as cmp forces you to. > > Our application has fairly straightforward tables and relations, typical > ecommerce type data, no big transaction concerns. I guess my main question > is this, is hibernate better, or does it come down to just a different > method than cmp (ie a strong argument for using a standard api vs > hibernate). > > Rick > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Cmp vs hibernate
onsdagen den 8 januari 2003 kl 17.23 skrev Bill Burke: Will hibernate provide you with a distributed clustered cache solution? JBoss 4.0 CMP will. If You are using hsqldbr(eplikated) - it probably would ... *hsqldbr(eplicated) http://www.javagroups.com/javagroupsnew/docs/hsqldbr/design.htm --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Cmp vs hibernate
Will hibernate provide you with a distributed clustered cache solution? JBoss 4.0 CMP will. Have the hibernate developers thought about clustering CMP? We have since JBoss 3.0. Bill Burke Chief Architect JBoss Group, LLC > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of LaBanca, > Rick > Sent: Wednesday, January 08, 2003 9:03 AM > To: '[EMAIL PROTECTED]' > Subject: [JBoss-user] Cmp vs hibernate > > > > A bit off topic, but I need to ask those who have explored... > > Has anyone here used hibernate in preference to cmp? If so how > has it worked > out for you in jboss? We are considering it or cmp. Hibernate certainly > seems more flexible, but I was thinking it doesn't abstract the > app from the > data as much as cmp forces you to. > > Our application has fairly straightforward tables and relations, typical > ecommerce type data, no big transaction concerns. I guess my main question > is this, is hibernate better, or does it come down to just a different > method than cmp (ie a strong argument for using a standard api vs > hibernate). > > Rick > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Cmp vs hibernate
In addtion, I would like to see CMP and Hibernate compared with Apache OJB: http://jakarta.apache.org/ojb/ Thanks, David -- LaBanca, Rick escribió:: A bit off topic, but I need to ask those who have explored... Has anyone here used hibernate in preference to cmp? If so how has it worked out for you in jboss? We are considering it or cmp. Hibernate certainly seems more flexible, but I was thinking it doesn't abstract the app from the data as much as cmp forces you to. Our application has fairly straightforward tables and relations, typical ecommerce type data, no big transaction concerns. I guess my main question is this, is hibernate better, or does it come down to just a different method than cmp (ie a strong argument for using a standard api vs hibernate). Rick --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Cmp vs hibernate
A bit off topic, but I need to ask those who have explored... Has anyone here used hibernate in preference to cmp? If so how has it worked out for you in jboss? We are considering it or cmp. Hibernate certainly seems more flexible, but I was thinking it doesn't abstract the app from the data as much as cmp forces you to. Our application has fairly straightforward tables and relations, typical ecommerce type data, no big transaction concerns. I guess my main question is this, is hibernate better, or does it come down to just a different method than cmp (ie a strong argument for using a standard api vs hibernate). Rick --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
