Sun renews its commitment to JDO with version 2.0

Discussions

News: Sun renews its commitment to JDO with version 2.0

  1. On Tuesday 20-Apr-2004, Sun submitted Java Specification Request 243 to the Java Community Process for Java Data Objects 2.0.

    The submission of this JSR represents a significant commitment by Sun to the effort to promote database-independent programming standards for Java.

    Sun also recently renewed its charter membership in http://JDOCentral.com. JDOCentral is a strong voice for vendors and users alike to promote the vision of JDO.

    JDO 2.0 will address many of the issues that have been raised against JDO 1.0.

    1. Binary compatibility is no longer a requirement. JDO vendors who have a better solution than byte-code enhancement can use it and still be compliant.

    2. Object-relational mapping will be standardized. Users can reuse the concepts as well as the metadata files from one implementation to another. Often, the biggest portability issue among vendors' products is the mapping file format.

    3. SQL support will be standardized. Users who must use SQL for practical or policy reasons will be able to use JDO for their object model and programming interface.

    4. Big-name support. With SAP, Oracle, and JBOSS (Hibernate) on the expert group there is now a critical mass of big companies sponsoring the effort.

    Once the JSR is approved for development by the Executive Committee of the Java Community Process, the expert group will be on a fast track to complete the specification and release it to the public. Most of the issues have already been discussed and resolved by a group of vendors and users.

    If TheServerSide readers are interested in influencing the direction of JDO, I'd encourage you to join the discussion here and at JDOCentral. If you have lots of spare time, you can even join the JDO 2.0 expert group. ;-)

    Visit the home of JSR 243 for Java Data Objects 2.0

    View the Minutes from the JDO 2.0 kickoff meeting from late last year.

    Threaded Messages (31)

  2. Looking forward the attach/detach feature as well as the standadized OR metadata mappings. Without a attach/detach, updating the persistent classes, in a web environment, could become quite tedious. I wonder if the attach/detach feature will be implmented by having the persistent class enhanced to carry the object id ,even when made transient, and then reassociated with a persistent object when the object becomes part of a JDO transaction? Also I wonder if there will be optimistic transaction support.

    Paul
  3. Re: attach/detach[ Go to top ]

    Looking forward the attach/detach feature as well as the standadized OR metadata mappings. Without a attach/detach, updating the persistent classes, in a web environment, could become quite tedious. I wonder if the attach/detach feature will be implmented by having the persistent class enhanced to carry the object id ,even when made transient, and then reassociated with a persistent object when the object becomes part of a JDO transaction? Also I wonder if there will be optimistic transaction support.Paul
    You're right on the money; the detached instance transparently carries its object id so that it can be re-associated with the correct DB record on attach. It also carries its version information so that optimistic lock violations can be detected (yes, attach/detach can be used with optimistic transactions too).

    Kodo JDO (http://www.solarmetric.com) includes a preview of the attach/detach features (probably not exactly the same APIs as the 2.0 spec will settle on, but the functionality is almost exactly the same), as well as some other JDO 2 preview features. I should mention that I work for them.
  4. Also I wonder if there will be optimistic transaction support.Paul
    I'm assuming you're wondering if the detachment APIs will support optimistic transactions. The answer is that yes, the JDO detachment APIs provide something akin to the offline optimistic lock pattern, in which collision detection occurs even after detachment and re-attachment. This is not quite the same as a full-fledged optimistic transaction, since it does not necessarily share all the other characteristics of a transaction (in particular, since the offline optimistic lock spans multiple database connections, there are no isolation level guarantees above READ_COMMITTED).

    If you were wondering if JDO 2 will support optimistic transactions in general, then the answer is yes, as, of course, JDO 1 already supports optimistic transactions.

    -Patrick

    --
    Patrick Linskey
    SolarMetric Inc.
  5. This is not quite the same as a full-fledged optimistic transaction, since it does not necessarily share all the other characteristics of a transaction (in particular, since the offline optimistic lock spans multiple database connections, there are no isolation level guarantees above READ_COMMITTED).
    It has nothing in common with optimistic locking if you are talking about "optimistic locking" in concurency control theory. Are you sure it guarantees READ_COMMITTED ? As I undestand it guarantees write/write conflict detection and nothing more.
  6. Offline optimistic locking pattern[ Go to top ]

    I barely know anything about JDO, but it sounds like what the parent post was referring to was the fact that these "transactions" will span multiple DB transactions, so even if the underlying connection has stronger guarantees than READ_COMMITTED those guarantees will not be preserved in the higher level optimistic transaction.

    I think the guarantee for READ_COMMITTED would simply come from the fact that the DB connection that originates the data doesn't allow dirty reads.
  7. Offline optimistic locking pattern[ Go to top ]

    Ok, I will try to model it.
    Let x is some data block and asume read(x)/write(x) are atomic ( guaranteed by hardware). Sequences of primityve operations are atomic and isolated for concurent execution (guaranteed by DB transactions).

     "DB transactions" become primityve operations if app spans multiple database connections. We have version number to detect conflic and to abort one of primityve operations (DB transaction).
     
    And looks like we have nothing more, "commit/abort" for application tranasaction
    is undefined so we have no end of "application transaction" and we can not define it as "action" (applications can define it as some "unit of work" itself).

    Our operations(DB transactions) are isolated, but secuences are not and all "reads" are "dirty".

    Algorythm can not abort this "transaction" if we have more than one "operation". There is no transaction state like txid, but application can define some and it can produce "cacading abort" or very compilated implementations where "optimistic locking" will have no value.

    This kind of "application transactions" have no transaction attributes so terms like "read commited" have no meaning in ths case and isolation is undefined.


    This is nothing bad and it can work in practice, some applications can work without transactions, but do not confuse transactions with version checking.
  8. IMHO, Sun should ditch JDO and make some variation of the Hibernate API standard. It's pragmatic and it works.

    I realize Gavin King is in the exper group; Gavin, can you comment on the JDO 2.0 enhancements - what do you think of it?

    I think it still sucks (but given your track record, I'm not blaming you :-)
  9. IMHO, Sun should ditch JDO and make some variation of the Hibernate API standard. It's pragmatic and it works.I realize Gavin King is in the exper group; Gavin, can you comment on the JDO 2.0 enhancements - what do you think of it?I think it still sucks (but given your track record, I'm not blaming you :-)
    Gavin is actually too busy participating on EJB 3.0 to comment :-)

    --
    Cedric
  10. weak[ Go to top ]

    In the past you have had some interesting comments on JDO, but this time you're pretty weak. "it sucks"...gimme a break. How 'bout you let Gavin speak for himself on JDO. Hey, I'm shocked that a weblogic CMP guy would hate JDO. BTW, I really liked Weblogic's CMP, I just moved on to JDO. JDO rocks, but I'm not impartial, nor are you.
  11. weak[ Go to top ]

    In the past you have had some interesting comments on JDO, but this time you're pretty weak. "it sucks"...gimme a break. How 'bout you let Gavin speak for himself on JDO. Hey, I'm shocked that a weblogic CMP guy would hate JDO. BTW, I really liked Weblogic's CMP, I just moved on to JDO. JDO rocks, but I'm not impartial, nor are you.
    What the hell are you talking about?!?

    I never said "sucks" nor any of what you are saying.

    My comment was exactly one line long and it was about Gavin participating in EJB 3.0. Reread it.

    Check your facts next time.

    --
    Cedric
  12. yikes[ Go to top ]

    I guess I should not post when I just got off a plane and have jetlag. My bad, I was reacting to the quote and in my sleep deprived state I flamed you by mistake. Should have known better than to read TSS when I could barely keep my eyes open.
  13. IMHO, Sun should ditch JDO and make some variation of the Hibernate API standard. It's pragmatic and it works.I realize Gavin King is in the exper group; Gavin, can you comment on the JDO 2.0 enhancements - what do you think of it?I think it still sucks (but given your track record, I'm not blaming you :-)
    Spoken like someone who has never really used JDO. I have yet to see a user who has given a good JDO implementation a chance and come away disappointed.

    Ditching JDO for Hibernate would be a huge step backwards. First, simply because JDO is here, it works well, and it has thousands of users, including paying customers. Second, because JDO is much more flexible than Hibernate.

    I'm not trying to degrade Hibernate in any way. Hibernate is great for what it is: *relational* persistence for Java objects. But JDO is much more; it can target any back end. Kodo JDO (http://www.solarmetric.com), for example, has a relational back end, a back end for Versant ODB, back ends targeting several legacy systems, and even an abstract generic back end you can extend for your own custom needs (as of the 3.1 release, set for any day now). And regardless of the back end, you get the same set of nice APIs and extras like remote persistence managers, distributed caching, etc. And yes, I work for those guys :)

    In fact, there was an article about JDO's flexibility in last month's JavaPro:
    http://www.ftponline.com/javapro/2004_03/online/jdo_jneal_03_10_04/

    Anyway, I encourage everyone to try JDO and make up your own mind on whether Sun should "ditch" it. IMO, the better solution is for Hibernate to become JDO-compatible. Luckily, that also looks like the more likely outcome.
  14. Well, I don't work with any backend. I work with a relational database and therefore only need an O/R mapping tool when the situation calls for it. I don't mind paying for software but if it can do all of the things you mentioned, and yet I am using a subset of it, I want the price to be reduced accordingly :) And yes I have played around with both JDO and Hibernate and to me JDO's insistence on persistence ( not just O/R ) is actually one of the things that turn me off a little bit.
  15. And yes I have played around with both JDO and Hibernate and to me JDO's insistence on persistence ( not just O/R ) is actually one of the things that turn me off a little bit.
    Could you be more specific? The top relational JDO implementations all offer features specific to relational DBs, such as direct SQL queries, very flexible mapping options, GUI O/R mapping tools, fetching via outer joins, etc. In fact, I don't know of any relational features of Hibernate that these implementations don't include.

    Many of these features will become standard in JDO 2.0. But they're already available in 1.0 implementations.
  16. And yes I have played around with both JDO and Hibernate and to me JDO's insistence on persistence ( not just O/R ) is actually one of the things that turn me off a little bit.
    Could you be more specific? The top relational JDO implementations all offer features specific to relational DBs, such as direct SQL queries, very flexible mapping options, GUI O/R mapping tools, fetching via outer joins, etc. In fact, I don't know of any relational features of Hibernate that these implementations don't include.Many of these features will become standard in JDO 2.0. But they're already available in 1.0 implementations.
    Every JDO Implementor tells you that feature x and feature y is already implemented and will become standard in JDO 2.0. The official JDO specification is now 1.0.1 and not 2.0. We can't compare all features from Hibernate and a JDO product xy and say that a big advantage is that our product is also a JDO implementation. I'm sure when you need a lot of the preview features you will have to migrate your software when the 2.0 spec is implemented from the JDO vendors.

    Reto Breitenmoser
  17. But JDO is much more; it can target any back end. Kodo JDO (http://www.solarmetric.com), for example, has a relational back end, a back end for Versant ODB, back ends targeting several legacy systems, and even an abstract generic back end you can extend for your own custom needs (as of the 3.1 release, set for any day now).
    I do not think it is a JDO feature, it is possible to implement JDBC driver for
    your own custom needs too ( it is much more usefull than pluggin for some JDO implementation ). Probably it is not very usefull in practice and looks like nobody needs this feature for hibernate.
  18. But JDO is much more; it can target any back end. Kodo JDO (http://www.solarmetric.com), for example, has a relational back end, a back end for Versant ODB, back ends targeting several legacy systems, and even an abstract generic back end you can extend for your own custom needs (as of the 3.1 release, set for any day now).
    I do not think it is a JDO feature, it is possible to implement JDBC driver for your own custom needs too ( it is much more usefull than pluggin for some JDO implementation ). Probably it is not very usefull in practice and looks like nobody needs this feature for hibernate.
    Tell the users of Versant, Poet, and other object databases that having a standard object persistence API isn't useful. Or the users of legacy systems that can now be accessed through JDO. Or customers who have customized a JDO implementation to store data in their own back end. Or in particular users who have switched from one back end to another thanks to JDO's abstractions. Do you think they'd agree with you?

    As I said, Hibernate is good for relational persistence. But so is JDO. I'm happy both systems are available to relational database users. I'll be even more happy if Hibernate eventually offers a JDO compatibility layer. But in the meantime, to suggest that Sun should throw out a great spec (JDO) in favor of a more limited product, nice as it may be, is ludicrous.

    p.s. Creating JDBC implementations for ODBs and legacy systems is not a solution. Not only is JDBC a much more complex API than JDO, and not only does it offer less benefits, but it would be horribly inefficient for certain stores, ODBs in particular.
  19. Probably you are right, I have never saw systems implemented with this kind of tools, but I think the best way to sell object oriented database is to implement SQL interface and ODBC,OLE DB, JDBC drivers for it.
  20. flexibility vs. specialization[ Go to top ]

    Second, because JDO is much more flexible than Hibernate.I'm not trying to degrade Hibernate in any way. Hibernate is great for what it is: *relational* persistence for Java objects. But JDO is much more; it can target any back end. Kodo JDO (http://www.solarmetric.com), for example, has a relational back end, a back end for Versant ODB, back ends targeting several legacy systems, and even an abstract generic back end you can extend for your own custom needs (as of the 3.1 release, set for any day now). And regardless of the back end, you get the same set of nice APIs and extras like remote persistence managers, distributed caching, etc.
    this has been discussed many times before from both angles, but I will repeat: The fact that JDO supports both relational and ODBMS (and other) backends is NOT a feature or advantage per se. As others said in this thread, there is very seldom any need to use that "flexibility". I have never seen a company with a reasonably big database considering to replace their RDBMS by an ODBMS - and for very good reasons at that. RDBMS do their job very well in a typical business context, and to this day ODBMS are no match.

    It is usually much (!) more important that the persistence tool makes all features and optimizations of the database accessible in an easy manner, instead of offering a least common denimator API. For example, with the exception of simple CRUD applications, JDOQL (btw, dont get me started on EJBQL) is doomed until it supports all the capabilities of SQL.

    Christian
  21. flexibility vs. specialization[ Go to top ]

    Interresting comments, Christian.

    You claim that "JDOQL is doomed until it supports all the capabilities of SQL". Have you looked at any of the published material about JDOQL in JDO 2.0? The query language has evolved significantly. It still acts at an Object-level abstraction, but with new features such as Aggregation (min, max, count etc.) and Projection (select just these fields from these objects and put them into an array or a JavaBean of the developer's design), JDOQL will have ample power. Combined with named fetch groups, you have the opportunity to write highly performant applications in a totally portable manner.

    Oh, and for organizations which must have a get-out clause in case they find JDOQL can't actually do that one special query that the DBA has written, JDO 2.0 standardizes the way to access a SQL connection which is enlisted into the current distributed transaction.

    Add to that the attach/detach API and I believe JDO 2.0 is extremely credible.

    That said, JDO 1.0.1 was not by any means broken. We have only had to deprecate one method from the jdo.jar file (PersistenceManager.makeTransietnt). I have personally worked on a number of successful projects using the JDO 1.0.1 standard. My clients achieved JDO implementation portability and were able to choose their implementation based on qualify of service factors, instead of being "locked in". I have also worked with clients to make applications work on ODBMS and SQL platforms since this was deemed important to the project stakeholders.

    JDO, and JDOQL, is useful far beyond CRUD-only applications.

    Kind regards, Robin.
  22. flexibility vs. specialization[ Go to top ]

    ... for organizations which must have a get-out clause in case they find JDOQL can't actually do that one special query that the DBA has written, JDO 2.0 standardizes the way to access a SQL connection which is enlisted into the current distributed transaction.Add to that the attach/detach API and I believe JDO 2.0 is extremely credible.
    Right. JDO is looking very healthy, feature-wise. It would be interesting to see what kind of mileage we can get out the attach/detach API in the context of a Web Services scenario - could be very useful. I hope that Hibernate evelves a JDO-compliant interface, so eventually we can get the best of both worlds.
  23. flexibility vs. specialization[ Go to top ]

    It is usually much (!) more important that the persistence tool makes all features and optimizations of the database accessible in an easy manner, instead of offering a least common denimator API.
    Relational JDO vendors all expose relational features "in an easy manner". They don't hide them. They allow users to perform direct SQL queries. They allow access to a the java.sql.Connection. They have APIs for eager fetching via outer joins. Etc, etc, etc.

    JDO gives you the best of both worlds. If you want to build an application that is going to be portable to different back ends, you can use "pure" JDO. If you want to take advantage of relational features, though, you are free to do so. In JDO 2, many of these relational features will be standardized. But even now, they're available. It doesn't make sense to dismiss a JDO implementation because some of its relational features aren't yet backed by the standard, and then turn to another relational product that has no standard backing at all.
  24. flexibility vs. specialization[ Go to top ]

    It is usually much (!) more important that the persistence tool makes all features and optimizations of the database accessible in an easy manner, instead of offering a least common denimator API.
    Relational JDO vendors all expose relational features "in an easy manner". They don't hide them. They allow users to perform direct SQL queries. They allow access to a the java.sql.Connection. They have APIs for eager fetching via outer joins. Etc, etc, etc. JDO gives you the best of both worlds. If you want to build an application that is going to be portable to different back ends, you can use "pure" JDO. If you want to take advantage of relational features, though, you are free to do so. In JDO 2, many of these relational features will be standardized. But even now, they're available. It doesn't make sense to dismiss a JDO implementation because some of its relational features aren't yet backed by the standard, and then turn to another relational product that has no standard backing at all.
    Actually, it makes a lot of sense much of the time, given that the product is free and open source. There's a fundamental difference in hitching yourself free open-source software that you can modify at will (or debug in case of issues), to hitching yourself to a proprietary, non-open-source product that has to be licensed for every developer. I'm not saying that there aren't other reasons you wouldn't want to use the proprietary commercial product, but essentially some of the reasons you wouldn't want to tie yourself to a proprietary commercial product just don't have the same weight when the product is free and open source. I want my proprietary products to be standards compliant so I can switch to somebody else if it is non-performant, the licensing cost becomes too high, I am worried about continued enhancements, etc. Assuming Hibernate has the feature-set I need for the project at hand, the standards aspect just doesn't have as much relevance as for the commercial product. I also ensure that all data-access is wrapped in Mapper/DAO objects in my IOC container (Spring), so it is relatively painless to switch to another O/R mapper later...

    Regards,
    Colin
  25. Saying that the JDO ability to manage various data storage is not an advantage - i.e. nobody changes its storage - is just the same as saying that JDBC ability to manage multiple RDBMS is not an advantage. Saying that JDBC drivers and SQL can handle every persistence need is also the same kind of statement about the ability to write everything better and more efficiently in C or machine code. I saw JDBC drivers written to manage digital video cameras, but I think this is not the best interface to do so. The issue is not about JDO vs JDBC, but about what level of API you need. You should just remember that what you are saying today about JDO was stated years ago about SQL itself, which was "an interpreted language, much less effecient that direct database APIs". In the information technology history, we heard the same kind of statements, again and again (about Object-oriented approach vs procedural, etc.) In my opinion the real issue is about cost, productivity and maintenability. Some applications will be better implemented using JDBC, and I think many others will be cheaper to implement and to maintain using JDO. Beyond that, the JDO-level of API is not just embedding SQL (or other storage concepts) statements in common objects concepts. As JIT compiler is able to perform optimization based on profiling info, a JDO API benefit from an abstraction level that allows to perform new optimizations for example (if I see insert then delete in the same transaction, I resolve it as NOP to take a simple example). Of course JDO implementations are not able to offer all of these kinds of things right now, but be sure they will. So, don't throw the baby with the bath water ;)
  26. JDO != Lowest Common Denomenator[ Go to top ]

    In an earlier posting to this thread, Christian commented:
    It is usually much (!) more important that the persistence tool makes all features and optimizations of the database accessible in an easy manner, instead of offering a least common denominator API.
    This "lowest common denominator" story is a common misconception about JDO. You might end up with such a scenario if you hand-wrote a persistence architecture yourself, using Sun's much-touted Data Access Object pattern. Whether the SQL is embedded in the DAO code or loaded from an external resource file, typically there is a lot of pressure to use the same (standard) SQL against all data stores.

    Many people suspect that JDO's enhancement of domain objects somehow injects into them the SQL statements they will use. This is a misconception; if true the resultant persistence-capable objects would not be portable unless only standard SQL was used (and even there, portability might be questionable).

    Instead, JDO defines an application-level API for the management of persistent objects. This is realized in the Persistence Manager interface. In addition, JDO suggests an implementation-level architecture and API through which persistence-capable objects can interact with the JDO implementation whenever they need to (such as when fields are read/modified or relationships traversed). The native protocol for invoking the data store’s services is not encoded into the persistence-capables. As a result, these domain objects are portable over any supported data store, and the SQL (in the JDO/R case) with which these objects are managed is generated by the JDO implementation in the full knowledge of exactly which version of which database is in use. This allows the proprietary features of a particular database vendor's dialect of SQL to be exploited to the full.

    If you do find something that your JDO 2.0 implementation does not achieve efficiently, then by all means get the native data store connection and do it yourself. But don't pre-optimise based on un-substantiated performance concerns (*). Write the application in the most appropriate abstraction layer and optimize only where genuine problems are evidenced. If your application involves Objects which must be dissolved into and reconstituted from a database, then the most appropriate abstraction layer may well be at the JDO level.

    As far as JDO features are concerned, JDO is a standard. With standards come portability of a defined set of features. JDO is a particularly good standard in that it splits its features into those that are "mandatory" and those that are "optional".

    "Mandatory" features are very well specified and must be supported by all JDO-compliant implementations. They provide a concrete guarantee of portability. "Optional" features are equally well specified. They provide a concrete guarantee of portability over all implementations which support that option. So the complete set of features is very well specified, but JDO implementations to run in microwave ovens don't have to provide for optimistic locking! ;-)

    Beyond the "Mandatory" and "Optional" features in the JDO specification, all vendors will always innovate beyond the spec. This is good (it furthers the state of the art in the industry), expected (few implementers of any JSR fail to optimize and provide added features), and necessary (in the Java world, the price that can be commanded by a "pure" JSR implementation without optimizations and added features must tend towards zero, as the RI is always free).

    "Lowest common denominator" has very little to do with JDO.

    Kind regards, Robin.

    * Naturally, application features known to be on the critical path as far as performance/scalability are concerned should be prototyped early in the development cycle.
  27. Are the experts on holidays?[ Go to top ]

    I've been tracking JDO2.0 for a long time. Especially with JDK1.5, I have some concerns including:
    1. Generics of collection be automatically recognized by enhancer so that collection-element-type needn't be specified in metadata anymore. (like already implemented in JDOGenie3.x, though not standardised)
    2. Annotations to specify bi-directional relations, such as a "@inverse" indication in java source code.

    The expert group seem to be busy on affairs other than JDO recently. A bit disappointed. :(
  28. Are the experts on holidays?[ Go to top ]

    Hi Bin

    The expert group is very busy at the moment. Defining a flexible O/R mapping specification is a lot of work. Attach/detatch is also a lot more complicated to define that it first appears.

    Using generics to avoid element-type, key-type and value-type attributes in the meta data has come up but not been finalized yet. I am sure this feature will be in JDO 2.0. As you mention JDO Genie already has it and it is very easy to implement.

    Annotations have also been briefly discussed.

    Cheers
    David
    www.jdogenie.com - JDO Genie - High Performance JDO for JDBC
  29. This is great news for the Java community. With JDO 2.0 we will have a mature standardized object-relational mapping solution for Java that doesn't suffer from some of the limitations of CMP EJB. JDO 1.0 does have some serious limitations but it seems that these are being addressed for 2.0

    Whilst Hibernate is a very cool solution there are advantages for many in having a framework based on a Sun standard and with the ability to pick and choose between commercial vendors.

    CodeFutures will be adding support to FireStorm/DAO for generating JDO 2.0 code as soon as the specifications are available for review.

    Andy Grove
    Code Futures, Ltd.
  30. JDO performance[ Go to top ]

    How does JDO compare in production? Can anyone give examples of JDO performing better or worse at high volume? And have you measured why it’s better or worse?

    Gary
  31. jdo is great![ Go to top ]

    I have been working with jdo for some months now and I can only say it's really nice.
    I've tryed jdogenie(love the rmi support), kodo and lido so far and there is things I like about them all. And if you want to take a look into it, you can read Robin Roos book for free as pdf.
  32. jdo is great![ Go to top ]

    And if you want to take a look into it, you can read Robin Roos book for free as pdf.
    As Simon says, my book Java Data Objects is available in full as a downloadable PDF. Of course I hope that some of you will choose to buy the hardcopy as well! You can register for the download through www.OgilviePartners.com.

    The Chinese printed edition of the same book has just been released in the last few days, ISBN 7-115-11804-3.

    So, does that make it 5 books dedicated to JDO?