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