Kathy, I don't think JDO will "kill" JDBC. It will, however, replace JDBC in a number of scenarios, especially when mapping data to objects, which is a good thing. However, I can imagine that there will always be scenarios where it is necessary to customize SQL with JDBC - especially when tightly integrating with the data store in question. This is similar to the case with CMP and BMP EJBs. However, just as using CMP is generally more preferred than BMP, it will most likely always be better to use JDO rather than JDBC wherever possible, thereby allowing the JDO vendors to take care of the persistence management and optimizations. Remember, though, that JDO will most likely run on top a JDBC layer, for a number of JDO vendors. So JDBC will continue to exist, although transparent to the developer. But it's use will probably be less than it it today (given that JDO catches on with the masses), which is a good thing in my opinion, since faulty persistence-management code is a big reason for faulty database applications today. P.S. Usually, the debate has been on JDO vs. EJB... you might also want to pursue that further Cheers,
I totally agree. The overhead of a JDO engine running on top of a JDBC layer as mentioned by Bjarki will translate into poorer performance, which few people may be prepared to live with, while others would rather stick with straight JDBC. It will be interesting to watch the evolution of JDO in terms of performance, community adoption, and its hypothetical integration within the J2EE Platform... (see the JDO vs EJB debate on TheServerSide) Franck Rasolo Independent Java Consultant London, UK
Hi Bjarki and Franck, Thank you for your replies. I was (am) following EJB vs JDO discussions, but my interest is in low-end (micro, embedded) solutions, where EJB is not an option. But as a side question - I haven't seen any EJB - JDO performance comparisons ... Would somebody risk an opinion? Kathy
Kathy, in my JDO chapter, I talk a bit about EJB and JDO. One of the things I mention there, and as the JDO architects point out in their specifications for JDO, is that JDO and EJB are not necessarily rivals. Instead, you could think of a scenario where the application developer has to use BMP beans. This has traditionally meant the use of JDBC code in the appliation logic, which usually eliminates the data store independence of the beans. Using JDO in the BMP bean, instead of JDBC, is therefore a possible alternative, that would help to preserve the seperation of business logic from persistence logic. But comparing EJB with JDO, one must consider the scenario in question. In a two or three-tier architecture, JDO might perform better than EJBs, considering the overhead of network communications associated with EJBs. But using JDO in a distributed environment (with custom made RMI code, possibly) would definitely be far worse than using EJBs. So there is probably no definite answer to this. Of course, we must keep in mind that JDO is still under community review, and there is no real experience yet with the JDO implementations from the vendor community. For that comparison, we must wait and see.
Originally posted by Kathy Shkarlet: Hi Bjarki and Franck, Thank you for your replies. I was (am) following EJB vs JDO discussions, but my interest is in low-end (micro, embedded) solutions, where EJB is not an option. But as a side question - I haven't seen any EJB - JDO performance comparisons ... Would somebody risk an opinion? Kathy
Well, this is a tough one, mainly for the following inter-related reasons: 1. The JDO spec isn't finalized yet. 2. Although many vendors have already announced or released beta products, none of the products fully integrates with existing J2EE application servers. This is due to the fact that support for the J2EE Connector Architecture in both JDO products AND J2EE application servers still needs to mature. You may have heard of Castor JDO, which is quite similar to the JDO standard although it doesn't implement it. Castor has been integrated with jBoss 2.x about 6 months ago. Someone on the Castor mailing list reported that the use of Castor JDO within Session Beans was indeed slower than straight JDBC. As to how it compares to EJB, my guess would be that it can be expected to be slower, again because of the many levels of indirection between the EJB container and the data store... Given my interest in JDO, I would obviously love to be proven wrong on this one ;-)
Franck Rasolo Independent Java Consultant London, UK