JBoss Chooses Java Data Objects

Discussions

News: JBoss Chooses Java Data Objects

  1. JBoss Chooses Java Data Objects (102 messages)

    According to JDO Lead Craig Russell, "....the JBoss team discussed their strategy for persistence outside the EJB tier. After investigating all the persistence APIs currently available, they concluded that Java Data Objects would be the best interface for them to use."

    If true, this would be the first time an appserver group acknowledged that persistence outside the EJB tier matters. It's not in an appserver vendor's interests to support JDO, because such a spec adds a lot of value to non-ejb development projects, reducing the value proposition for the EJB container. Perhaps JBoss' move, along with the new 'express' editions of Weblogic and Websphere will mean more attention for JDO from Sun and the big vendors.

    Excerpt from the latest newsletter (which was emailed today) from JDOCentral.:

    JBoss chooses Java Data Objects
    by Craig Russell


    Several months ago, Marc Fleury announced that JBoss would make their CMP implementation available to developers working on persistence solutions outside the server environment. With no details, rumors flew about what this actually meant for persistence and the open source community.

    Today, almost no-one uses BMP any more as the power of CMP is proven and working. In other words, if the CMP2.0 engine's applicability goes beyond EJB alone, why couldn't we imagine a CMP engine working on abstract plain old java objects? We will look at making it the default service for persistence in JBoss. In fact I would argue that CMP2.0 is doing what JDO failed to do, providing a robust and framework-worthy persistence engine for Java (once generalized). While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along. Marc Fleury, Why I Love EJBs.

    But after looking at the alternatives, the JBoss team changed their tune. This week at JavaOne, the JBoss team discussed their strategy for persistence outside the EJB tier. After investigating all the persistence APIs currently available, they concluded that Java Data Objects would be the best interface for them to use.

    According to Alexey Loubyansky, the author of JBossDO, At first, I planned to write our own framework for POJO persistence. I looked at Java Data Objects, Hibernate, OJB, a couple of others and decided to start with Java Data Objects. At least to have it as the base. And it is really a good spec. Thank you.

    Dain Sundstrom, a committer of JBoss CMP, concurred that they plan to use their persistence abstraction engine, developed for CMP, to abstract user-visible APIs, starting with CMP for the server and Java Data Objects outside. This approach will allow them to support other APIs as customers demand.

    The race is now on to be the first Java Data Objects standards-compliant open-source product. With JORM, TJDO, XORM, OJB, and now JBossDO in the running, this promises to be a very interesting competition that will greatly benefit the Java Data Objects community and Java developers all over the world.

    Threaded Messages (102)

  2. is this good or bad ?[ Go to top ]

    So is that going to improve their CMP implementation or distract from it
  3. What bothers me here is having a new powerful branch in the J2EE stream. This means Jboss not recognized by SUN but well recognized by the community will go its own way in the J2EE world which will create more and more incompatibility among different J2EE application providers. JDO might be better then CMP because there is nothing worse then that but all it means is forget about cross platform compatibility, it is really reminds me old IE Netscape story.
  4. Valdimir[ Go to top ]

    Open Source is the only powerfull J2EE stream. I am no big fan of EJB (I use iBatis/Tomcat/Resin), but Sun is a dying company.
    http://www.pbs.org/cringely/pulpit/pulpit20030213.html
    They are doing some desperate moves now, but to late I think.

    Look at their market share:
    http://news.netcraft.com/archives/2003/04/10/java_servlet_engines.html
    Theye are more of a trickle than a Stream. (or see www.tpc.org)

    Some heatlhy compeitor representing Java must emerge, ex IBM.
    Or in this case open source!
    http://www.penguincomputing.com/graphics/desktops/eclipse1280x1024.jpg
    I realy think that Sun has the potential to embaras Java developers.
    If they do, then at least CLI is ECMA standard and C# is not all bad:
    http://go-mono.com/faq.html
    and look at for web apps: http://mavnet.sourceforge.net/

    Look how big open source is relative:
    http://news.netcraft.com/archives/2003/06/12/june_2003_web_server_survey.html
    Now that is a stream.
    I think after Sun goes the way of Data General and others, JBoss will still be arround and a strong stream.

    .V
  5. Valdimir[ Go to top ]

    If they do, then at least CLI is ECMA standard and C# is not all bad:


    Rolf, Is that you ?? we missed you !!! Thanks for the laugh!
  6. JDO is a standard, specification, why the hell it should not be cross-platform? You can choose implementation from JBOSS, Exadel, Kodo whatever – it should work, unless specific implementation is not standard compliant. There is a problem with mapping to specific database structure – but that is a problem anyway, in most cases you just need to recreate mapping.
  7. The race is now on to be the first Java Data Objects standards-compliant open-source product. With JORM, TJDO, XORM, OJB, and now JBossDO in the running, this promises to be a very interesting competition that will greatly benefit the Java Data Objects community and Java developers all over the world.


    TJDO is far the most compliant today
  8. I find this highly amusing since there has been a feature request from september 2001 (http://sourceforge.net/tracker/index.php?func=detail&aid=457650&group_id=22866&atid=376688) that wasn't even so much as looked at or commented on as far as I can tell.
  9. I still like the power and flexibility of using SQL and parsing result sets. It provides the opportunity to finely tune the application in database-specific ways (not fun, but practical and realistic).

    Let's face it, the biggest problem with JDO isn't its vision/philosophy (any pure OO guy has wet dreams about persisting value objects). The problem with JDO is two fold. First, there are tons of legacy systems that contain a wealth of data in RDBMS's. Porting that data from RDBMS to OODMBS will not yield any short to medium term ROI, and it is unlikely that it will ever yield a significant ROI in the longer term.

    Until one of the big database vendors comes-out with a secure, scalable, stable, feature-rich OODBMS, it doesn't make much sense to move away from a very flexible, very tune-able approach. Furthermore, using some sort of JDO adapter (Castor, z.b.) might enable you to switch to another true JDO vendor at a later time. Very likely, however, is it that the true JDO vendor will have some unexpected implementation idiosynchrosies that necessitate refactoring.

    There is a wide variety of developers out there that knows how to use SQL, and know how to embed SQL into an entity bean (or even reference an external SQL repository with a key mgt system). This SQL can be passed-on to an RDBMS specialist for tuning. Then, whether you are building your application against a legacy database or a brand spaking new database you'll have an app that zips, that is fairly straight forward, and that is relatively easy to maintain.

    As we continue to push the Java envelope, we are pushing more layers of abstraction that is necessary in most cases. For current time-and-place intents and purposes, JDO isn't the answer unless you're building a small application that doesn't require massive amounts of throughput, and that won't end up having 10,000 classes (rampant object creation desctruction is a very yucky side-effect of any application genericity).

    K.I.S.S. and you'll succeed. Get overzealous with genericizing everything and you'll likely fail.

    As much as I love the concept of JDO, until that killer app comes along, we're all better-off building on the foundation the RDBMS folks have left as their legacy.

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  10. John in Desert[ Go to top ]

    I used to do RowSet, etc. low level. I do not like O/R.

    Then... I switched to iBatis... and it's a big improvment but gives me all the low down power withint a DAO framework.

    .V
  11. CMP far from a no-brainer decision...[ Go to top ]

    I don't have anything to say about the pros and cons of JDO, having never used it myself. But one particular detail struck me:

    >> rampant object creation desctruction is a very yucky side-effect of any application genericity <
    The creation/destruction of short-lived objects costs relatively little in modern JVMs. On my Athlon 1500, I can create 10,000,000 small objects and garbage collect them in 750 milliseconds. The time required for creation and destruction of 10,000 small objects (and I think you were using the number 10K as hyperbole) would be swamped by the I/O required to talk to the database.

    I think this is just one example of a growing trend: the code we write is so many layers of abstraction away from the metal (and the "metal" is getting so fast) that developer intuition as to what's fast (and what's "fast enough") no longer holds. It's often impossible to say that approach X is slower than approach Y, unless you have run tests in the context of a realistic application. For example, it might be true that using JDO rather than binding your app directly to the RDBMS could allow you to creating caching mechanisms for your business objects that could otherwise be difficult or inconvenient. (That's just a "for instance", please do not discuss the merits of that particular notion!)

    I am trying to make two points here. 1) Just by writing Java code, we are far enough away from the metal that you really need to make empirical judgements WRT performance. 2) Adding layers of abstraction do not always slow things down; sometimes the additional layers can improve performance by allowing new kinds of optimization.
  12. \Cheng\
    The creation/destruction of short-lived objects costs relatively little in modern JVMs. On my Athlon 1500, I can create 10,000,000 small objects and garbage collect them in 750 milliseconds. The time required for creation and destruction of 10,000 small objects (and I think you were using the number 10K as hyperbole) would be swamped by the I/O required to talk to the database.
    \Cheng\

    You'd think so, but your numbers don't bear out under realistic tests. One very popular app server spends 5%-10% of its time garbage collecting when under heavy load. That has a noticable impact on overall server throughput.

    The problem with your test is that you did it in a vacuum. GC's quick if that's all you're doing. If you happen to have other threads out there that are actually doing real work at the time - like servicing requests - then GC can cause significant contention in your app. Throw in the fact that in many JVM's GC takes place in a single thread and locks out other threads, and a GC can add in significant latency to requests taking place when the GC pause happens.

    In short - you broke your own rule about "run[ning] tests in the context of a realistic application". Run a big Java app under JProbe or the like which doesn't concern itself with optimizing object creation, and be prepared for a shock at the percentage time a real app spends just doing GC.

         -Mike
  13. This was exactly the type of response I had in mind...

    In a single JVM the object creation/destruction won't have too demonstrable an effect. In fact, depending on the type of application you are writing, abstraction and layers might server a purpose if going generic is somehow a cornerstone of the application concept. In fact, going-generic is how we've arrived at the current J2EE model. After a certain point, though, there is a diminishing return on the amount gained in terms of time and/or monetary savings from the generic-ness that is achieved. At some point, it's time to stop building applications for applications and to start building applications for people.

    Considering the ever-increasing size of the internet, the potential demand for a killer webapp is astounding. In fact, these days, I don't even bother building an application that won't appeal to a wide variety of people, and that doesn't have the potential to draw thousands of concurrent users. Every fabric of my being these days is spent with an eye toward maintainability and performance.

    After exploring solutions like Castor, Versant, and Cocobase, I've found that good ol' fashioned SQL, along with good pattern choices for managing the storage, population, and retrieval of SQL statements and for the parsing and distribution of the ResultSet data is the most practical, workable solution.

    To respond to the object creation issue, as the system scales, so too does the number of operations. If the number of operations grows too quickly with the number of users, then the application reaches the point of failure more quickly. If I can save four or five object creations per user request, over the course of billions of user requests, I'll preserve many, many app server cycles. Scaling better at the caching/app-server tier means that I'll save more money on hardware. I'f I'm using a simpler approach that isn't so generic, my system will likely be more maintainable by a wider variety of people, and I'll likely spend less money over the products life cycle. It also means I'll have less hands in the kitchen.

    Once again, K.I.S.S. and you'll likely succeed. Over genericize and you'll likely fail.

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  14. Please, read a book about JDO[ Go to top ]

    John, please take a closer look to JDO spec and several books that already exists. It looks like you are not so familiar with JDO. Believe me, JDO is not Object Database, it is a layer between plain Java objects and some (any) datastore – presumably relational database. The whole idea of JDO is simplicity.
  15. it is a layer between plain Java objects and some (any) datastore ? presumably relational database.


    That is the biggest JDO problem: it tries to be generic enough to allow ANY datastorage.
    IMO: RDBMS oriented OR mapping should not be mixed with generic persistence (Hibernate, Cocobase, TopLink and alike are good examples of the approach). Too generic approaches are flawed (CMP, JDO...)
  16. CMP far from a no-brainer decision...[ Go to top ]

    You'd think so, but your numbers don't bear out under realistic tests. One very popular app server spends 5%-10% of its time garbage collecting when under heavy load. That has a noticable impact on overall server throughput.

    >
    > The problem with your test is that you did it in a vacuum. GC's quick if that's all you're doing. If you happen to have other threads out there that are actually doing real work at the time - like servicing requests - then GC can cause significant contention in your app. Throw in the fact that in many JVM's GC takes place in a single thread and locks out other threads, and a GC can add in significant latency to requests taking place when the GC pause happens.
    >
    > In short - you broke your own rule about "run[ning] tests in the context of a realistic application". Run a big Java app under JProbe or the like which doesn't concern itself with optimizing object creation, and be prepared for a shock at the percentage time a real app spends just doing GC.
    >

    Not true anymore. In the past yes, single threaded GC was a problem. GC is becoming less of the bottleneck it was now that concurrent and parallel GC implementation are available. GC is only limited by number of processors, the processors' speed and cache size. Allocation has always been parallel, and now collection is also parallel. (ie. check spec.org for specjbb results).
  17. CMP far from a no-brainer decision...[ Go to top ]

    \d taye\
    Not true anymore. In the past yes, single threaded GC was a problem. GC is becoming less of the bottleneck it was now that concurrent and parallel GC implementation are available. GC is only limited by number of processors, the processors' speed and cache size. Allocation has always been parallel, and now collection is also parallel. (ie. check spec.org for specjbb results).
    \d taye\

    I wouldn't say "not true" any more. Perhaps "less true" would be more accurate. I've played with some new 1.4 based JVMs, and they do indeed both allocate faster and have different GCing behavior.

    But memory still isn't free, and GC still isn't instantaneous. And there are still a large number of people running on 1.3 based JVMs.

        -Mike
  18. Castor is NOT JDO[ Go to top ]

    Just in case if somebody do not know yet...
  19. "I still like the power and flexibility of using SQL and parsing result sets. It provides the opportunity to finely tune the application in database-specific ways (not fun, but practical and realistic)."


    Agreed. But the number of situations where there is a need to fine tune the SQL in my experience is a small proportion to the overall application size. IMHO it is quite acceptable to custom craft small critical sections of an application rather than writing tons of code everywhere.

    > "Porting that data from RDBMS to OODMBS will not yield any short to medium term ROI, and it is unlikely that it will ever yield a significant ROI in the longer term."

    The argument for JDO applies to a context far wider than the argument for OODBMSs. It would be mistaken to confuse one with the other.

    > "Until one of the big database vendors comes-out with a secure, scalable, stable, feature-rich OODBMS, it doesn't make much sense to move away from a very flexible, very tune-able approach. Furthermore, using some sort of JDO adapter (Castor, z.b.) might enable you to switch to another true JDO vendor at a later time. Very likely, however, is it that the true JDO vendor will have some unexpected implementation idiosynchrosies that necessitate refactoring."

    I can turn around that argument and say that switching RDBMSs can result in similar idiosynchrasies. There are no ideal solutions out there.

    > "There is a wide variety of developers out there that knows how to use SQL, and know how to embed SQL into an entity bean (or even reference an external SQL repository with a key mgt system). This SQL can be passed-on to an RDBMS specialist for tuning. Then, whether you are building your application against a legacy database or a brand spaking new database you'll have an app that zips, that is fairly straight forward, and that is relatively easy to maintain."

    App that zips - maybe, easy to maintain ? Not in my opinion.

    > As we continue to push the Java envelope, we are pushing more layers of abstraction that is necessary in most cases. For current time-and-place intents and purposes, JDO isn't the answer unless you're building a small application that doesn't require massive amounts of throughput, and that won't end up having 10,000 classes (rampant object creation desctruction is a very yucky side-effect of any application genericity).

    In fact the cost of understanding JDO or any OR Mapping tool and learning to use it makes it prohibitively expensive to use it in a small application especially if most of the team is not used to it. It is precisely the large applications where the development / maintenance productivity benefits make a strong argument in favour of JDO or an O-R Mapper.

    > K.I.S.S. and you'll succeed. Get overzealous with genericizing everything and you'll likely fail.

    How about being "just" zealous ? ;)

    > As much as I love the concept of JDO, until that killer app comes along, we're all better-off building on the foundation the RDBMS folks have left as their legacy.

    In the meanwhile lots of others are happily leveraging it to their own benefits.

    Dhananjay
  20. JDO hard to learn?[ Go to top ]

    Hi Dhananjay

    "the cost of understanding JDO or any OR Mapping tool and learning to use it makes it prohibitively expensive to use it in a small application"

    I agree with your post except for this point. JDO is *very* easy to learn and use. It should not take more than an hour to get your first JDO app up and running if you try one of the commercial implementations. This is especially true of new projects where you do not have to map to an existing database as JDO will create the schema.

    We recently met with a skilled Java consultant wanting to learn about JDO. We showed him our demos and he said let me try. He quickly wrote a couple of normal Java classes, copied and edited build.xml from our demo, used our GUI Workbench to create a project and set connection properties and got his main method persisting his model in 10 minutes. His comment: "this is impressive".

    Cheers
    David
    JDO Genie - High Performance JDO for JDBC
  21. JDO hard to learn?[ Go to top ]

    Apologies for making a broad generalisation. Would like to place my original statement in the following context.

    a. The struggle to get used to O-R mapping and actually feel comfortable with it is the bigger struggle than the actual tool usage in the early days (with teams who have never done O-R mapping in the past and which are very competent with SQL otherwise).
    b. With larger applications, it actually takes quite some time to understand the intricacies of a tool and its interaction with the database to make sure its outputs remain reasonably functional and performant under complex situations.

    I have been working using various O-R mappers almost consistently since 96, across a number of projects and products. I do think it takes much more effort and understanding than what the typical tutorials or quick-start guides that accompany various products would lead us to believe for serious large sized applications. (in defence of the O-R tools, thats actually true for most other tools as well ;) ).

    Cheers
    Dhananjay
  22. JDO hard to learn?[ Go to top ]

    I have been working using various O-R mappers almost consistently since 96, across a number of projects and products. I do think it takes much more effort and understanding than what the typical tutorials or quick-start guides that accompany various products would lead us to believe for serious large sized applications. (in defence of the O-R tools, thats actually true for most other tools as well ;) ).

    >

    I agree. Using JDO, I'm still learning, because I need to think different. I used to use DAO pattern, and now I need to think only in my bean.
  23. * up-front statement for full disclosure: I wrote a book on JDO and my company could be considered to be a JDO Consultancy - oh, and I'm on the expert group *

    I believe JDO to be easy to learn - a 3-day training course is usually sufficient, and can include specifics of a particular JDO implementation's O/R mapping features as well as JDO iself. Compare that to the training requirement to get people up to speed with alternative techniques, particularly those currently in the J2EE platform. And of course it is useful that JDO training IS available for JDO, from a nuber of providers world-wide (including my company).

    The real learning curve with JDO is object modelling. For too long we've been writing simple JavaBean classes to act as Value Objects, because our persistence techniques were not capable of managing much more complexity. With JDO (and some non-standard alternative O/R mappers) persisting complex object graphs with statc relationships (inheritance & implementation hierarchies) and dynamic relationships (association, aggregation, composition and various cardinalities thereof) is almost trivial.

    The lesson we need to learn now is how to build propper object models that combine state and behaviour and foster reuse, flexibility and maintainability. Our skills in Object Modelling have been unduely constrained by the lack of viable transparent persistence technology until now.

    Kind regards, Robin.
  24. * up-front statement for full disclosure: I wrote a book on JDO and my company could be considered to be a JDO Consultancy - oh, and I'm on the expert group *

    >
    > I believe JDO to be easy to learn - a 3-day training course is usually sufficient, and can include specifics of a particular JDO implementation's O/R mapping features as well as JDO iself. Compare that to the training requirement to get people up to speed with alternative techniques, particularly those currently in the J2EE platform.
      
    JDO might be easier than some other implementations. However compared to hibernate ? I would doubt it.
    > The real learning curve with JDO is object modelling. For too long we've been writing simple JavaBean classes to act as Value Objects, because our persistence techniques were not capable of managing much more complexity. [.. snip ..] Our skills in Object Modelling have been unduely constrained by the lack of viable transparent persistence technology until now.
     
    I would beg to offer a different opinion. I started working with Persistence in 7 years ago (that was C++), and have worked with a number of tools since then. I am not sure how you define transparent, but except for the early days of Java, I've never felt the lack of viable persistence technology which bridges the Object Relational gap. (Granted - each implementation had its own gotchas .. which is unlikely to change). I havent really seen any significant development within the Object-Relational space for a looong time except for an awkward sideways step called CMP, and a really innovative approach in hibernate (bypassing both code generation and compile time byte code generation). JDO is just yet another specification. The advantage of JDO is that it is a standard, not that it is necessarily better or easier to use or offering more features or for that matter easier to learn. It gives you abilities to switch implementations relatively easily. Having said that each tool/spec have their own contexts where they deliver better value than others.

    The real challenge is to continue modeling objects as objects, tables as a relational data providers, and <emphasis> use them together with the minimum of sacrifices or compromises </emphasis> in order to build highly maintainable and performant software - quickly.
  25. 'Performant'.

    It's not a real word, however :)

    Skol!

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  26. 'Performant'. It's not a real word, however :)

    Its a french word which is infrequently used in english (and especially software) contexts. Do I sense a slight resentment against French words entering corrupting Queen's English ? ;)
  27. I start with an object model.

    I move to a domain model.

    I translate my domain model to an RDBMS.

    The most time consuming part of this is vetting out the domain model. The translation from UML to ERD is trivial.

    Once there, I'm using a proven method for accessing the data, and I'm translating it very quickly to entity properties and dependent value objects (where it is necessary to combine multiple data elements that comprise a cohesive concept).

    This is much more viable than the introduction of JDO, not IMHO, but in my experience.

    Best,

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  28. \John Dale\
    I start with an object model.

    I move to a domain model.

    I translate my domain model to an RDBMS.

    The most time consuming part of this is vetting out the domain model. The translation from UML to ERD is trivial.
    \John Dale\

    I'd like to echo what you're saying. There seems to be an underlying current of thought here that just plain using SQL & JDBC somehow involves alot of code, or that it locks you into your RDBMS too much, or it's too hard. In my experience, none of that is true. For example, I do alot of work with stateless session beans which use straight JDBC, and that's my translation layer from Objects to relational, with transactions and distributed access (if desired) contributed by the EJB. I generate boilerplate EJB/JDBC code based on XML descriptions of data transfer objects. SQL is treated as objects held in configuration, so it's easily changable outside the code. This works well, is easy to understand/debug/maintain, easily tweakable, and doesn't involve alot of grunt coding effort. The only gotcha is my boiler-plate generator - which took all of a week to development.

    Some may argue that going with a real "product" to do the same thing would be a better investment, but in my experience there's so much "implicitness" in such systems that it's tough to tell what's really going on in the code, it can be very difficult to introduce new people to the project to, and it's not always easy or obvious to figure out how to optimize pieces that are performing poorly.

    My approach is very straight forward, very explicit, and doensn't make the mistake of trying to do too much in one layer. It's _just_ doing transactions, to/from the database. Things like object modelling doesn't belong in that layer.

         -Mike
  29. I'd like to echo what you're saying. There seems to be an underlying current of thought here that just plain using SQL & JDBC somehow involves alot of code, or that it locks you into your RDBMS too much, or it's too hard. In my experience, none of that is true. [..snip..] I generate boilerplate EJB/JDBC code based on XML descriptions of data transfer objects. SQL is treated as objects held in configuration, so it's easily changable outside the code. This works well, is easy to understand/debug/maintain, easily tweakable, and doesn't involve alot of grunt coding effort. The only gotcha is my boiler-plate generator - which took all of a week to development.


    Congratulations on developing your own O-R mapper. If thats what works for you - great. But if the underlying current as you referred to was completely misplaced, I believe it is unlikely you would have spent the time to create your own O-R mapper.
  30. I think Mike has found a nice balance between diminishing return and practicality.

    It works for him.

    He doesn't have to buy licenses.

    It has a small footprint (I imagine).

    It's easy to understand.

    It's portable.

    It's still SQL-oriented.

    It's not a giant money-sucking-pit-of-a-leap.

    John C. Dale
    DITD
  31. \Dhanajay Nene\
    Congratulations on developing your own O-R mapper. If thats what works for you - great. But if the underlying current as you referred to was completely misplaced, I believe it is unlikely you would have spent the time to create your own O-R mapper.
    \Dhanajay Nene\

    What I created wasn't an O-R mapper by any stretch of the imagination. It's no more than a very lightweight framework, some utilities, and sensible modularization. At its heart, it's nothing more than a very convenient way to use JDBC.

        -Mike
  32. Do you program in assembler too John?[ Go to top ]

    You are not anybody who can be impressed by JDO. By your own admission, you don't even use it. You are just like assembler programs saying that it's better than C. What nonsence. You cannot be blind to the other benefits in thinking/designing/programming in terms of an object model. To say that SQL is perhaps more efficient is irrelevant. That is not the discussion. We assume there will be a performance price to pay for an abstraction - there always is.

    Also, to call it "bloated persistence layer" is nonsence too. If yo uhaven't actually used any of the commercial JDO engines how can you say this? Is Java a bloated implementation layer sitting on top of the perfect assembler

    It's a fantastic move by JBoss to support JDO. It in no way impinges on their other persistence support - why should it. And, JDO is portable so great. I may have to buy a JDO engine for an alternative app server, but so what. Who knows, if tJDO and JBoss JDO get together that could be an awesome opensource portable JDO implementation.

    So everything is positive. Non-believers, stuck in the past, move on.
  33. Do you program in assembler too John?[ Go to top ]

    \a a\
     You cannot be blind to the other benefits in thinking/designing/programming in terms of an object model. To say that SQL is perhaps more efficient is irrelevant.
    \a a\

    RDBMS tables are not objects. Storing and retrieving data from potentially very large data stores is _not_ the same thing as a method call. And the prime reason here is all about efficiency. If you happen to think that efficiency is "irrelevant", and that OO modelling is more important, then I have to ask - what do you do when your users complain that the system is too slow? What if executed tasks are missing business deadlines? Do you throw up your hands and say "that's the price to pay for abstraction"?

    I think not. Developer efficiency is not the only factor in the equation. Maintainability is not the only factor. The durn thing has to also work, and it has to work fast enough to meet the business needs. And many people use straigthforward techniques because they're proven to work, and work "fast enough". Not necessarily blazingly fast, but fast enough.

    \a a\
    Also, to call it "bloated persistence layer" is nonsence too. If yo uhaven't actually used any of the commercial JDO engines how can you say this? Is Java a bloated implementation layer sitting on top of the perfect assembler
    \a a\

    <grin> In many ways, Java is exactly that. But for most server side "business" programming, it's proven to be fast enough. On the flip side, O/R abstraction layers haven't yet been proven to be beneficial overall for really large, performance critical applications. It may work in some situations, but there are still many cases where a lower level mechanism makes alot of sense (and in fact may be the only workable solution).

    As I said awhile back in another thread - newer does not always mean better.

         -Mike
  34. Both sides have their reasoning and I belive it is all due to the timing.
    Once the performance overhead is so insignificant, programming in objects is
    the way to go. This kind of abstraction has been basically then
    computer history, from assembling language to J2EE framework.

    We have argued not to use C++ for the performance reason and so not Java
    for the server side. The counter-arguments all have been right, but only
    for that time being. With hardware impvements, SQL will disappear from
    the business tier. It is there now, but won't be there all the time.
  35. Humans aren't Primates...[ Go to top ]

    JDO going against an RDBMS still executes SQL my friend.

    SQL will evolve such that it doesn't resemble what it is today, however.

    Saying that SQL won't exist is kind of like saying Humans aren't Primates.

    Prost!

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  36. John,

    Of course most JDO implementations uses SQL. They would not if SQL wasn't a lower-level API.

    The fact is just that SQL is well-suited for retrieving column-level data from relational databases, but that use cases of today's application are more and more about retrieving objects, navigating though them, etc.

    The point is not to say that JDO is the new silver bullet to do anything. JDO is not intended to build reusable components (use EJBs instead, maybe with JDO inside or CMP/JDO if they are persistent components). JDO is not intended to access database for low-level operations (use JDBC/SQL instead, even if most of JDO implementations allows you to use plain or semi-object SQL if you need it).

    JDO is intended to provide transparent persistence for plain Java objects. If you don't need that, use SQL or something else. But if you need that, I would recommend you to use JDO, because trying to do so with SQL and your hands will cost you a lot. Either it will cost you the build of a new framework tailored for each new application, or the maintenability and development of an all-datasources framework tailored and optimized for every RDBMS/ODBMS/legacy systems that you might encounter in your architect career. The latter is what JDO provides. It may even cost you some performance loss, because of lack of implemented good caching systems, datasource-specific tuning, and even use case-oriented tuning.

    There is a read added value in the today's JDO, and even more is the future of JDO. Let's avoid diving in the same kind of debate we heard about Java (who says today that it's too slow or only for client-side applets ?) or even SQL (ask people that saw the birth of SQL and they will tell you that at this people people complained that SQL wasn't optimized, interpreted, limited, and that and better alternative was using the low-level database APIs instead).

    Regards,

       Jérôme Beau
       http://libelis.com

    > JDO going against an RDBMS still executes SQL my friend.
    >
    > SQL will evolve such that it doesn't resemble what it is today, however.
    >
    > Saying that SQL won't exist is kind of like saying Humans aren't Primates.
    >
    > Prost!
    >
    > John C. Dale
    > CEO, Chief Architect
    > Down in the Desert, Inc.
  37. Object Translation...[ Go to top ]

    Entity Beans were invented specifically for caching. Why bother with a fat JDO framework that does redundant work?

    Translating from object graphs to an RDBMS takes very little time, especially with an optimized IDE like IntelliJ's IDEA. Furthermore, I've found that I'm writing just as much metadata as code (I'm writing the routines to C.R.U.D. a User object once and using that from other components, not re-writing the User C.R.U.D. SQL every time I need it). Have you ever had the need to adjust the JDO metadata during production runtime? If this was a requirement, then I might consider separation of code from persistence metadata a better thing. By the time I'm ready to adjust persistence code, I'm using my IDE, and another build will be required to release to production anyway. At that point, it's just a matter of deploying another EAR file to my cluster and I'm done with it having margaritas at the local cantina.

    One of the reasons Java is so fantastic is because of the scrutiny (Hagel's Synthis, Antithesis, Thesis approach). In many ways it drove the creators of Java to make their language better. I think the same thing will happen with JDO. It is a cool philosophy, which is why there is such hubub about it. Eventually, once one of the big vendors picks-it-up (Oracle, IBM, Microsoft ha ha) and makes a robust toolset that allows me to persist retrieve objects without 1) post-processing my compiled objects, 2) writing huge amounts of XML metadata and 3) suffering a huge performance hit, I'll buy-in. Give me an interface and uses the DB server-side cycles to C.R.U.D. objects and serializes them over the wire. When THAT is released, I'm very much on board.

    Best,

    John C. Dale
    DITD
  38. Again an inverse logic[ Go to top ]

    Entity Beans were invented specifically for caching. Why bother with a fat JDO framework that does redundant work?


    No, entity beans were invented to allow components to have a persistent state while remaining reusable (i.e. independent from any persistence solution in any context, which is the aim of CMP). Adding caching capabilities (which are quite limited to non-prescriptive commit options) to EJBs is just the consequence of lack of efficient persistence Java API at this time. Caching capabilities are quite better stated in the JDO specification (ignoreCache, cache queries, retainValues) and JDO vendors goes beyond this.

    Again, to me, this is just a matter of layers : EJB is for components and may use
    JDO. JDO is for objects and may use JDBC. JDBC is for RDBMS and may use SQL, RDBMS native APIs and protocols.

    So the problem is rather that JDO cames after EJBs, while it should have been out before them. It it was the case, it would looked as natural to everyone that EJB used JDO to implement their CMP service.

    So while the timeline may it look as the opposite, the redundancy is in the opposite direction. EJB CMP did some persistence work while waiting for JDO. To EJB transparent persistence is just a consequence of the goal of reusability (in various applications/infrastructure contexts). To JDO, transparent persistence is this only goal. It is not an all-services API which overhead of distribution, security services if you don't need need. If you need all that, use EJBs.

    > Translating from object graphs to an RDBMS takes very little time, especially with an optimized IDE like IntelliJ's IDEA.

    Very good IDE indeed :)

    > Furthermore, I've found that I'm writing just as much metadata as code (I'm writing the routines to C.R.U.D. a User object once and using that from other components, not re-writing the User C.R.U.D. SQL every time I need it).

    Of course, but is your SQL optimized for that database ? Are your SQL results cached ? Are all your developpers JDBC and database experts ? What about these routines if you change your database or if your change the datasource paradigm (ODBMS, legacy) ? You might have to rewrite more than a SQL line, but a big part of your data access layer. Using JDO, you'll have to write new mapping metadata. No changes to code, including no changes to queries' text (which remain at the object layer, using objects semantics).
     
    > Have you ever had the need to adjust the JDO metadata during production runtime? If this was a requirement, then I might consider separation of code from persistence metadata a better thing. By the time I'm ready to adjust persistence code, I'm using my IDE, and another build will be required to release to production anyway. At that point, it's just a matter of deploying another EAR file to my cluster and I'm done with it having margaritas at the local cantina.

    JDO metadata can include various tuning aspects of your choice (indexes, cursors, fetch groups, etc.), depending the your JDO vendor capabilities. You enhance again, and you'll have margaritas too :) By the way JDO can be included in any J2EE application, as it has been designed to (leveraging JCA).
     
    > I think the same thing will happen with JDO. It is a cool philosophy, which is why there is such hubub about it. Eventually, once one of the big vendors picks-it-up (Oracle, IBM, Microsoft ha ha) and makes a robust toolset

    Oracle has a problem because their product (TopLink) uses reflection (which is slower and more code-intrusive than enhancement) and so cannot be JDO-compatible. So they spread FUD about JDO. IBM will probably buy some JDO vendor. Microsoft tries to show ObjectSpaces as their JDO competitor but ObjectsSpaces is more close to EJB 2.0 (abstract persistence accessors) than JDO (no code modification). Furthermore JDO will probably be part of J2EE 1.5, so those vendors will have to ship it.

    > that allows me to persist retrieve objects without 1)
    post-processing my compiled objects

    If you look for performance you might rather choose enhancement than other techniques (introspection, etc.). By the way such a post processing is getting more and more transparent (just see IDE plugins from JDO vendors).

    > 2) writing huge amounts of XML metadata

    I would bet a lot that you write at least much more metadata *and additional code* in a EJB+JDBC solution (including J2EE+EJB descriptors+JDBC code+object translation code+cache code+SQL queries) than in a JDO application (metadata+datastore-agnostic JDO queries)/

    > 3) suffering a huge performance hit,

    Just try a good JDO implementation like LiDO. And compare it with a similar code that build the same objects as a result, navigate them, etc. Maybe you have a false opinion of JDO because you experienced Castor JDO, which is not JDO despite its name.

    > I'll buy-in. Give me an interface and uses the DB server-side cycles to C.R.U.D. objects and serializes them over the wire. When THAT is released, I'm very much on board.

    Try it and tell us if you're on board :) And don't forget your development costs and time to market.
  39. Again an inverse logic[ Go to top ]

    I think that to not use Entity EJBs as an intelligent persistent cache is the mis-apply the concept. The throughput that results from caching is the primary advantage of building a J2EE system, IMHO. You bring-up a good point, however, in that EJBS provide an excellent opportunity for reuse. That model (and thousands of implementations) was around long before EJB. A standard-ized intelligent cachine model is much younger than the concept of componentizing for reuse purposes.

    "So the problem is rather that JDO cames after EJBs, while it should have been out before them. It it was the case, it would looked as natural to everyone that EJB used JDO to implement their CMP service."

    I think that RDBMS's came along before Objects were widely used and understood. This, more than your line of reasoning, might be why JDO is having its problems.

    "I would bet a lot that you write at least much more metadata *and additional code* in a EJB+JDBC solution (including J2EE+EJB descriptors+JDBC code+object translation code+cache code+SQL queries) than in a JDO application (metadata+datastore-agnostic JDO queries)/ "

    The upside, however, is that most engineers can easily read and maintain it.

    Best,

    John C. Dale
  40. Again an inverse logic[ Go to top ]

    "Again, to me, this is just a matter of layers : EJB is for components and may use
    JDO. JDO is for objects and may use JDBC. JDBC is for RDBMS and may use SQL, RDBMS native APIs and protocols.

    So the problem is rather that JDO cames after EJBs, while it should have been out before them. It it was the case, it would looked as natural to everyone that EJB used JDO to implement their CMP service. "

    I've found that building a session bean facade for JDO, does a good job in replacing entity beans. Perhaps that has how entity beans should have been implemented in the first place ?
  41. Mike,

    You and I seem to be on the same page.

    I prefer to externalize my SQL in ejb metadata, where it can be quickly popped into a Prepared Statement and executed. I tend to use Entity Beans as the exception (when an intelligent cache can effectively be employed to increase throughput for a common service) rather than the rule, and love going directly to the database from a Session Bean where caching provides no advantage (this entailes sometimes refactoring an entity bean-in when user useage patterns would indicate an advantage - an easy thing to do with a straight forward approach).

    I'd be interested to hear more about your XML approach to producing SQL. How would you go-about including SQL hints in that case without a bunch of rigoramal in your parser? Maybe I'm not understanding exactly how the system works. In any case, it sounds like a nice simple approach that doesn't hinder the development process as much as it helps it (a goal JDO will likely not achieve for quite some time).

    Now, back to the issue.

    I have done assembly, but there is no need to do it because C was developed to encapsulate many of the common tasks in assembler. I rarely do C because I prefer a language that allows me to effectively cohesively create and package objects with their operations (much easier for me, an OO guy, to understand and refactor when necessary). I rarely use C++ because of the complexity of the build framework (make is robust, but ant is like ice cream on a hot Phoenix Summer Day), and because it doesn't port well. I use Java because it encapsulates many of the cool things about C++, which encapsulates many of the cool things about C, which encapsulates many of the cool things about Assbembler, which encapsulates many of the cool things about the operation upon contiguous memory by commands stored in n-byte registries. These techologies have evolved and matured to the point that there is no diminishing return in employing them. As I've argued thus far, I think there IS a diminishing return on attempting to employ JDO in a meaningful way (interpret as assumptions about bottom dollar and time to market being foundational considerations) AT THIS TIME. Employing C, C++, or Java before they were ready for prime-time would and did cost a lot of money. I'll leave those types of activities to companies who have billions of investor dollars to throw at the problem.

    I'm a small business owner with very practical needs. I strongly believe that to have any chance in my various market opportunities, I'll have to eliminate obvious risks to success like JDO, and stick with that I know works.

    I'll say it again, just for grins. If/when JDO is proven by those who have lots of investor dollars to find out, I'll reconsider adopting it. In the meantime, I'll stick with what I know, and be happy to reduce risk where I can.

    Cheers,

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  42. I've seen this argument many times, and don't buy it.

    Sure, it's simple to get a simple application running. You can copy the darned examples that ship with the product. That doesn't mean that mapping to your domain/data model and producing a meaningful, scalable application will be equally as easy.

    Once you get it out of the box, JDO becomes quite difficult to understand in the context of 'correct application'.

    Prost!

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  43. Try this fast demo on how to build a JDO application with EclipseJDO

    http://www.tutorial-omondo.com/jdo/judo/first_flash.html
  44. Some counter-points...[ Go to top ]

    -Agreed. But the number of situations where there is a need to fine tune the SQL -in my experience is a small proportion to the overall application size. IMHO it -is quite acceptable to custom craft small critical sections of an application -rather than writing tons of code everywhere.

    You can just never predict when or where you'll need to optimize. I've worked on two large products that made us of O/R mapping. In both, we'd wished we would have just kept it simple and used vanilla SQL to DB. Apps that are simple and CONSISTENT are easier to maintain. By introducing a third party O/R mapper, you've 1) introduced a potentially large library of code and required knowledge into the system, increasing the footprint and propensity for inneficiency, and 2) made it necessary for a developer to understand two methodologies in order to maintain the system. What if your O/R mapper company goes out of business? It's just not worth it in my experience.

    -The argument for JDO applies to a context far wider than the argument for -OODBMSs. It would be mistaken to confuse one with the other.

    I haven't used JDO ODMBS since using Gemstone's Persistent Cache. I know the spec has evolved since then, and maybe someday I'll have a reason to take another look. For now, however, I'm having great success with SQL where I've previously failed with a bloated third party mapping layer in my applications.


    - App that zips - maybe, easy to maintain ? Not in my opinion.

    I'm not speaking from opinion here, I'm speaking from experience building production enterprise applications. They are easier to maintain when they are cohesive and consistent, especially at the persistence tier.

    -In fact the cost of understanding JDO or any OR Mapping tool and learning to -use it makes it prohibitively expensive to use it in a small application -especially if most of the team is not used to it. It is precisely the large -applications where the development / maintenance productivity benefits make a -strong argument in favour of JDO or an O-R Mapper.

    Explain to me how that prohibitive cost doesn't increase exponentially with the size of the team...

    Cheers!

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  45. Some counter-points...[ Go to top ]

    If you're writing a large application with huge amounts of SQL embedded within it, I'm very curious to see how you've set your project up to deal with change and refactoring. I have done a great deal of work with using straight SQL, stored procs, etc., and have found that on any project of reasonable size and complexity, the overwhelming amount of SQL that needs to be created is extremely difficult to manage. I don't mean that to be disparaging; I'm just curious what practices or patterns you use to manage the complexity. As I keep trying to tell people over and over with database applications, the biggest cost to any project is not due to failure to optimize speed that's already hampered by the i/o limitations of database access, but due to managing complexity and change.

    As I mentioned, I have worked with and built frameworks that have used SQL pretty close to the metal. Once I discovered hibernate and realized that I would only need to create relatively simple mapping files once, and that I wouldn't have to write SQL to deal with every normal database operation, I was tremendously relieved. I was even happier when I realized that I could still use SQL for the 1% of the time it was necessary for functionality or optimization purposes. IMHO, there's no real way to do things closely tied to SQL on a large project without using code generation, which brings its own host of issues.
  46. Managing SQL...[ Go to top ]

    The key to managing SQL is to externalize it and access it with Keys. A SQL statement should be treated like a function or method. It has input (parameters to a PreparedStatement) and output (ResultSet).

    Once you know these, it's usually best to develop a utility class for handing the parameter population (Dates vs. Strings vs. Ints, etc.), and parsing routines that can be encapsulated in an EJB or DAO.

    Person isa Entity isan Expert at persisting herself.

    I've put them in Property files, EJB metadata, and embedded them in the code (not as desireable).

    My favorite method is making the SQL prepared statement Strings accessible via a context jndi lookup (can be accessed from the web app context or ejb context). It looks something like this for an EJB:

    <env-entry>
        <env-entry-name>mySQLKey</env-entry-name>
        <env-entry-type>java.lang.String</env-entry-type>
        <env-entry-value>
    </env-entry-value>
    </env-entry>
  47. Managing SQL..[ Go to top ]

    The key to managing SQL is to externalize it and access it with Keys. A SQL statement should be treated like a function or method. It has input (parameters to a PreparedStatement) and output (ResultSet).

    Once you know these, it's usually best to develop a utility class for handing the parameter population (Dates vs. Strings vs. Ints, etc.), and parsing routines that can be encapsulated in an EJB or DAO.

    Person isa Entity isan Expert at persisting herself.

    I've put them in Property files, EJB metadata, and embedded them in the code (not as desireable).

    My favorite method is making the SQL prepared statement Strings accessible via a context jndi lookup (can be accessed from the web app context or ejb context). It looks something like this for an EJB:

    <env-entry>
        <env-entry-name>mySQLKey</env-entry-name>
        <env-entry-type>java.lang.String</env-entry-type>
        <env-entry-value>
            select someVals from someTables where someCol = ? some other col = ?
        </env-entry-value>
    </env-entry>

    Then, if you need to construct it dynamically, you can do something like this:

    <env-entry>
        <env-entry-name>mySQLKeyPrefix</env-entry-name>
        <env-entry-type>java.lang.String</env-entry-type>
        <env-entry-value>
            select someVals from someTables where someCol = ? <insert string from you code at this point and append the suffix>
        </env-entry-value>
    </env-entry>

    <env-entry>
        <env-entry-name>mySQLKeySuffix</env-entry-name>
        <env-entry-type>java.lang.String</env-entry-type>
        <env-entry-value>
            group by someCol
        </env-entry-value>
    </env-entry>


    This approach externalizes the SQL, allows for optimization and database idiosynchrosies.

    Best,

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  48. Managing SQL..[ Go to top ]

    I do precisely the same thing as you do, except that I don't stick my SQL config into EJB metadata, but instead load it seperately from a different file. This has the minor advantage of not tying me to EJB's.

    My own SQL is strictly split up in the config file to minimize duplication of information. For example, I always split up select stuff, from stuff, and where stuff so I don't need to keep respecifying it. Something like:

        userInfo=first_name,last_name, user_name, userid

        getUserByID=select $(userInfo) from users
                     where user_name = ?

        getFooUsers= select $(userInfo) from users, foo
                       where someCondition=? and foo.userid = users.userid

        ....

        insertNewUser=insert into users ($userInfo) values ( ?, ?, ?, ?)

    Of course, I auto-generate most of the baseline information (like userInfo above) from my XML definitions.

         -Mike
  49. nice approach...[ Go to top ]

    I used to have a level of discomfort with tying into Entity EJBS and Session EJBs.

    I found that I spent a lot of time trying to figure out different patterns and policies for running inside/outside a container. To make a long story short, I jumped in head first. Now, I just use the J2EE model for most of my applications. Any time I need database interaction, since I've gotten so fast at building/deploying services, I just do a new service and make it remoteable for a standalone client. I wrote an XML-based SQL population framework from scratch as an excercise. I abstracted the entire SQL parse-tree into an XML schema and was able to describe and dynamically populate all kinds of SQL. In the the time I spend plunking around with that had been spent analyzing use-cases and building straight forward production code, I would have been better-off.

    Who knows, maybe someday I'll write an App Server to-spec. I feel I could do this, but quite frankly it won't pay the bills (as many software support infrastructures will not). As a whole, in order to repair our reputation in industry (software development), we need to start applying technology to help end-users. The days of writing software for software are over. It's time to start focusing more on the community of citizens, not just the community of developers.

    I like your approach, honestly. It's a nice incremental step. It's a nice way to componentize SQL in an understandable way, and in the process you haven't put webbed feet on a duck, nor have you significantly defaced the object of your efforts.

    Best,

    John C. Dale
    DITD
  50. Some counter-counter-points...[ Go to top ]

    -Agreed. But the number of situations where there is a need to fine tune the SQL -in my experience is a small proportion to the overall application size. IMHO it -is quite acceptable to custom craft small critical sections of an application -rather than writing tons of code everywhere.

    >
    > You can just never predict when or where you'll need to optimize.
    And usually I dont except for some obvious situations. I prefer to address these after profiling the code and identifying the bottlenecks.
     
    >> - App that zips - maybe, easy to maintain ? Not in my opinion.
    >
    > I'm not speaking from opinion here, I'm speaking from experience building production enterprise applications. They are easier to maintain when they are cohesive and consistent, especially at the persistence tier.

    In my humble "experience" time taken to maintain a smaller code base is usually smaller. I have also experienced a much higher proportion of defects in projects that did not use O-R mapping than those that did especially for all feature enhancements which required changes to the schema.

    >> -In fact the cost of understanding JDO or any OR Mapping tool and learning to -use it makes it prohibitively expensive to use it in a small application -especially if most of the team is not used to it. It is precisely the large -applications where the development / maintenance productivity benefits make a -strong argument in favour of JDO or an O-R Mapper.
    >
    > Explain to me how that prohibitive cost doesn't increase exponentially with the size of the team...

    Simple ! Variable cost of writing persistence related code is much much lower under O-R mapped scenarios than otherwise. Its the fixed cost of learning O-R mapping, and understanding the tool (and delving into its guts at times) thats expensive. It would be very hard for me to understand scenarios where the variable cost of writing persistence code is higher for O-R mapped scenarios cos I've never seen that happen. YMMV.
  51. Some counter-counter-points...[ Go to top ]

    \Dhananjay Nene\
    In my humble "experience" time taken to maintain a smaller code base is usually smaller. I have also experienced a much higher proportion of defects in projects that did not use O-R mapping than those that did especially for all feature enhancements which required changes to the schema.
    \Dhananjay Nene\

    For comparable projects using radically different frameworks, this assertion does not hold true at all. Complexity of the code, "dynamicism" and implicit behavior of the code, etc are huge modifying factors. A "small" code base can actually be very complex, with lots of implicit/hidden behavior and high levels of dynamic behavior. This can be very, very difficult to maintain - particularly if an enhancement requires you to step out of the implicit behavior, and you don't happen to have a good idea how to do that.

    In addition - configuration complexity also comes into play. If you have very dynamic code which relies heavily on external configuration info (like, say, an O/R mapper's app configuration), then you may have less code, but a much more complex configuration.

    I generally like very dynamic solutions, but at the same time I try to balance that with explicitness when I can. Writing explicit code can be a bit of a pain, but it has the great virtue of being child's play to figure out when problems crop up, or you need to do something unusual. In contrast, very dynamic solutions use alot of hidden, implicit behavior, and it can be the very devil trying to isolate a problem, and doing anything out of the ordinary (from the framework's viewpoint) often means writing far uglier configs/code to get that unusual job done.

    \Dhanajay Nene\
    Simple ! Variable cost of writing persistence related code is much much lower under O-R mapped scenarios than otherwise. Its the fixed cost of learning O-R mapping, and understanding the tool (and delving into its guts at times) thats expensive. It would be very hard for me to understand scenarios where the variable cost of writing persistence code is higher for O-R mapped scenarios cos I've never seen that happen. YMMV
    \Dhananjay Nene\

    This isn't even close to being true, if you consider it from a real working perspective. You're just trading code size/complexity for configuration complexity. Managing a system with 500 tables is going to be _lots_ more difficult than managing one with 50 tables - whether you're using an O/R tool or doing it yourself. If you believe otherwise...well, then we've obviously worked on very, very different sorts of systems. In my experience, as your total app size goes up, the "bang" you get from something like an O/R mapper goes way down, and the seeming cost of rolling by hand actually doesn't increase, but decreases, because teams invariably create their own mini-frameworks to handle the complexity.

        -Mike
  52. Metadata...[ Go to top ]

    I had completely forgotten about this aspect.

    Using an O/R mapper or JDO implementation is a lot like sweeping the dirt under the rug. The dirt is still there, it's just a little more hidden from view.

    -but it has the great virtue of being child's play to figure out when problems
    -crop up

    The crux of the issue. Head meets nail. Right on the nose, yadda yadda.

    It's faster, as easy/easier to produce, and is easier to maintain.

    A hard knocks lesson when $ is on the line.

    Nice response.

    John C. Dale
    DITD
  53. \Dhanajay Nene\

    > Simple ! Variable cost of writing persistence related code is much much lower under O-R mapped scenarios than otherwise. Its the fixed cost of learning O-R mapping, and understanding the tool (and delving into its guts at times) thats expensive. It would be very hard for me to understand scenarios where the variable cost of writing persistence code is higher for O-R mapped scenarios cos I've never seen that happen. YMMV
    > \Dhananjay Nene\
    >
    > This isn't even close to being true, if you consider it from a real working perspective. You're just trading code size/complexity for configuration complexity. Managing a system with 500 tables is going to be _lots_ more difficult than managing one with 50 tables - whether you're using an O/R tool or doing it yourself. If you believe otherwise...well, then we've obviously worked on very, very different sorts of systems. In my experience, as your total app size goes up, the "bang" you get from something like an O/R mapper goes way down, and the seeming cost of rolling by hand actually doesn't increase, but decreases, because teams invariably create their own mini-frameworks to handle the complexity.
    >

    I would think that it would be much easier to scale to 500 tables from 50 tables with a reusable abstracted interface than writing, debugging, evolving, and maintaining 450 new SELECT statements, 450 new INSERT statements, 450 new UPDATE statements, and 450 new DELETE statements. Good OR-Mapping products relieve you from mundane, repetitive and error-prone job of writing and maintaining complex JDBC/SQL code. Won't hand-coding of thousands of low-level SQL statements impact the time, cost and risk of developing your application negatively?

    Configuring your mapping with a non-intrusive OR-Mapping product like JDX may actually improve the design, modularity and evolution of your application as you don't have to find and change multiple SQL statements every time you make a little modification in your object or relational model.

    OR-Mapping products can also take care of generating appropriate DDL statement for your target database or reverse-engineering object-model from existing schemas to give you a nice jump-start towards developing your application. These tasks certainly become non-trivial as the number of classes/tables grows.

    Unless you are dealing with a very small set of tables or your data access needs are only "relational", you should be able achieve great productivity gains by using a flexible, non-intrusive, and dynamic OR-Mapping technology like JDX. And from performance point of view, a lot of optimizations (like connection pooling, using prepared statements, minimizing number of database calls, etc.) have already been incorporated into these frameworks such that they perform comparable to and sometime even better than raw JDBC implementations.

    Developing your own mini-frameworks is another alternative but why reinvent the wheel when optimized, market-proven, and cost-effective solutions are already available?

    -- Damodar Periwal

    Software Tree, Inc.
    Simplify Data Integration
    http://www.softwaretree.com
  54. Party line...[ Go to top ]

    No offense, but this is all party-line stuff that loses merit on the development floor.

    When the rubber hits the road, there are few people beyond the developers of the O/R product who can use O/R mappers effectively.

    I respect where you're coming from and what you've done, but O/R mappers have too much down-side for me personally (previous posts regarding risk of ownership).

    Cheers!

    John C. Dale
    DITD
  55. PS...[ Go to top ]

    yer website has da purty flash.

    ;)

    John C. Dale
    DITD
  56. -I would think that it would be much easier to scale to 500 tables from 50
    tables with a reusable abstracted interface than writing, debugging, evolvi-ng, and maintaining 450 new SELECT statements, 450 new INSERT statements, 450 new UPDATE statements, and 450 new DELETE statements. Good OR-Mapping products relieve you from mundane, repetitive and error-prone job of writing and maintaining complex JDBC/SQL code. Won't hand-coding of thousands of low-level SQL statements impact the time, cost and risk of developing your application negatively?

    The crux of Mike and I's arguments were that it takes just as much time and effort (and runtime performance sacrifice) to maintain metadata for 450 new inserts, updates, and deletes (respectively) as it does to maintain the inserts, updates and deletes directly. Developers already know JDBC, they rarely know a third party O/R.

    As the application gets THAT big, you're looking at a lot of development no matter WHAT. With legacy systems especially, in the time it would take to LEARN how to apply your tool, you could have been well on your way to APPLYING a direct JDBC approach that has standard intuitive patterns for joining, normalizing, denormalizing, etc., to the nth degree.

    Again, not to know your product, but I prefer the manual approach.

    Best,

    John C. Dale
  57. Additionally you can generate SELECT, INSERT, UPDATE and DELETE SQL statements from the scheme. So you only have to write the scheme for the table and then use a SQL generator for the CRUD operations. (see ResultSetMetaData)
  58. The crux of Mike and I's arguments were that it takes just as much time and effort (and runtime performance sacrifice) to maintain metadata for 450 new inserts, updates, and deletes (respectively) as it does to maintain the inserts, updates and deletes directly. Developers already know JDBC, they rarely know a third party O/R.

    >

    Well, 3 lines of JDX mapping metadata can potentially save 300 lines of JDBC/SQL code. The savings could be much more if complex object structures and class hierarchies are involved. As I mentioned, performance impact could be minimal with a fine-tuned OR-Mapping engine. There is sure a learning curve involved in using any new technology (even a simple VCR). But if 3 days of learning can save 3 months of work, it may be worthwhile.
       
    > As the application gets THAT big, you're looking at a lot of development no matter WHAT. With legacy systems especially, in the time it would take to LEARN how to apply your tool, you could have been well on your way to APPLYING a direct JDBC approach that has standard intuitive patterns for joining, normalizing, denormalizing, etc., to the nth degree.

    I agree there are advantages of using direct JDBC/SQL in some situations (BTW, JDX allows use of direct SQL) but most of the time, IMHO, reducing the low-level complexity through OR-Mapping can save a lot of time, money and frustration especially in BIG projects. This whitepaper describes a few pitfalls of using direct JDBC.

    >
    > Again, not to know your product, but I prefer the manual approach.

    I understand your reservation. I hope that some testimonials can help you open you up a little bit to check out JDX.

    Best,

    -- Damodar

    Software Tree, Inc.
    Simplify Data Integration
    http://www.softwaretree.com
  59. These claims are unfounded...[ Go to top ]

    I say this with a bit of reservation, but...

    Have you used your product personally successfully in the market for a highly trafficed site?

    Also, and I mean no disrespect, but it is more difficult to consider your point of view since you work for the company.

    3 lines of jdx code saves 300 lines of code. If I have an engineer who can write 300 lines of code in 3 days, and I pay that engineer 200 dollars per day, that's 600 dollars for those three lines of code. How much would your product cost, and would I have any code written in the first three days (very critical stage when your business people are screaming for software)?

    At some point, if the project was alive long enough, and your product was actually productive and there was a low turnover rate for engineers, the price paid for your product would be recouped.

    My viewpoint is this. J2EE implementations are products that save a great deal of time. Many people are trying to 'ride-the-wave' of J2EE by introducing productivity products. Since I'm only interested in writing big apps, the more third-party software I stuff in there the worse-off I'll be as the application grows in size. I'm a minimalist becase:

    I get better performance.
    I get more maintainable code.
    I get a smaller footprint (runtime and otherwise).
    I have a cost-savings.

    Prost!

    John C. Dale
    DITD
  60. Performance and ROI with JDX[ Go to top ]

    I say this with a bit of reservation, but...

    >
    > Have you used your product personally successfully in the market for a highly trafficed site?

    We have been selling JDX for the last 5 years and currently it is shipping in version 4.0. Our customers have used JDX for some heavy-duty applications with high-performance requirements. Here are some case-studies.

    >
    > Also, and I mean no disrespect, but it is more difficult to consider your point of view since you work for the company.

    I understand and appreciate your skepticism, which is fair. I hope customer testimonials and case-studies make it a little easier for you to consider giving JDX a shot.

    >
    > 3 lines of jdx code saves 300 lines of code. If I have an engineer who can write 300 lines of code in 3 days, and I pay that engineer 200 dollars per day, that's 600 dollars for those three lines of code. How much would your product cost, and would I have any code written in the first three days (very critical stage when your business people are screaming for software)?
    >
    > At some point, if the project was alive long enough, and your product was actually productive and there was a low turnover rate for engineers, the price paid for your product would be recouped.

    I am pretty confident that one would be able to achieve much more with JDX than with raw JDBC in the first 3 days. The productivity gains beyond the first few days will be much more dramatic as one becomes more familiar with the framework and the associated tools. In terms of ROI, the current cost of JDX license is $1495/developer seat (no runtime). It will more than pay for itself in a couple of weeks. And the resulting code will be much more intuitive, compact, maintainable and easy-to-evolve.

    >
    > My viewpoint is this. J2EE implementations are products that save a great deal of time. Many people are trying to 'ride-the-wave' of J2EE by introducing productivity products. Since I'm only interested in writing big apps, the more third-party software I stuff in there the worse-off I'll be as the application grows in size. I'm a minimalist becase:
    >
    > I get better performance.
    > I get more maintainable code.
    > I get a smaller footprint (runtime and otherwise).
    > I have a cost-savings.

    Interestingly, those are the benefits our customers reap when using JDX. With a small runtime footprint of just 405 KB, JDX's lightweight OR-Mapping infrastructure becomes much more attractive if the number of classes/tables increase since the fixed overhead gets leveraged over a large number of classes. And add the all-important time-to-market advantage.

    Your mention in another post about the concern for vendor-viability is understandable. Even big public companies like PeopleSoft can't be taken for granted. I guess you won't be buying any software from any company other than IBM and Microsoft:)
     
    Best,

    -- Damodar Periwal

    Software Tree
    Simplify Data Integration
    http://www.softwaretree.com
  61. Nice post..and thanks...[ Go to top ]

    I don't 'buy' software. I only buy hardware. I rely heavily on the open source products.

    Won't say which, but suffice it to say that my only overhead is licenses of IntelliJ IDEA.

    Best,

    John C. Dale
    DITD
  62. Nice post..and thanks...[ Go to top ]

    I don't 'buy' software. I only buy hardware. I rely heavily on the open source products.

    >
    We have company of sorts. I usually don't buy 'hardware'. I am happy with my old single-head screwdriver. I use it even for four-head (Philips) screws. Power screwdriver is not for me. What if it saves me time and energy? People don't appreciate the thrill of working with time-tested tools in all sorts of different ways even if the tool was intended to be used only in certain ways. People are too lazy to figure out how far a simple screwdriver can go. They even buy a hammer. Tsk.. tsk..

    -- Damodar
  63. The crux of Mike and I's arguments were that it takes just as much time and effort (and runtime performance sacrifice) to maintain metadata for 450 new inserts, updates, and deletes (respectively) as it does to maintain the inserts, updates and deletes directly. Developers already know JDBC, they rarely know a third party O/R.


    Todays OR tools are mature enough and provide tools to reverse engineer schemas. If the build process accomodates the database synchronization , there is "NO" effort involved in creating and maintaining the persistent objects that the application needs.

    As for the argument that few developers understand OR mapping tools, any decent java developer can come to grips with working with such tools without breaking sweat. That is my experience
  64. \Dandapani\
    Todays OR tools are mature enough and provide tools to reverse engineer schemas. If the build process accomodates the database synchronization , there is "NO" effort involved in creating and maintaining the persistent objects that the application needs.
    \Dandapani\

    Generally, you don't want really want a one-to-one mapping of database tables to classes in many projects. Therefore, you need to create classes that represent your object model, and then map those classes to your database tables. This cannot be done automatically unless you have a one-to-one relationship.

    Second, the default SQL that the tool creates may not be the best SQL for what you're trying to do, so again customization is needed.

    In short - no O/R mapper can take a set of classes and a database schema and magically figure out what goes where. It just doesn't work that way.

    I agree O/R mappers are cool if you can accept all of the defaults and auto-generate everything. The crux of my argument is that you can't do that very well in complex applications/environments.

         -Mike

  65. > Generally, you don't want really want a one-to-one mapping of database tables to classes in many projects. Therefore, you need to create classes that represent your object model, and then map those classes to your database tables. This cannot be done automatically unless you have a one-to-one relationship.
    >
    Agreed. The point is: you still need to persist to relational tables and you still need to write SQL. A lot of application code involves simple CRUD operations and hand-writing SQL is a waste of time for such simple SQL (and especially so if the tables involve several columns). The drudgery that is eliminated is worth the investment in JDO. Adding new columns to the database to support new requirements can be a real pain if hand-coded SQL is used.

    > Second, the default SQL that the tool creates may not be the best SQL for what you're trying to do, so again customization is needed.
    >
    For the CRUDs(which I think are significant in many apps that talk to a database), the sql generated is so trivial that hand-coded optimizations may not be required. If and when optimizations are required, it is OK to hand-code JDBC for these situations. There is never going to be a 100% one-solution-fits-all approach that is perfect. Complex queries will have to be hand-written. But most updates/inserts/deletes do not fit in this category.

    .
    >
    >      -Mike
  66. Some counter-counter-points...[ Go to top ]

    \Dhananjay Nene\

    > In my humble "experience" time taken to maintain a smaller code base is usually smaller. I have also experienced a much higher proportion of defects in projects that did not use O-R mapping than those that did especially for all feature enhancements which required changes to the schema.
    > \Dhananjay Nene\
    \Mike\
    > For comparable projects using radically different frameworks, this assertion does not hold true at all. Complexity of the code, "dynamicism" and implicit behavior of the code, etc are huge modifying factors. A "small" code base can actually be very complex, with lots of implicit/hidden behavior and high levels of dynamic behavior. This can be very, very difficult to maintain - particularly if an enhancement requires you to step out of the implicit behavior, and you don't happen to have a good idea how to do that.

    > In addition - configuration complexity also comes into play. If you have very dynamic code which relies heavily on external configuration info (like, say, an O/R mapper's app configuration), then you may have less code, but a much more complex configuration.
    \Mike\

    I agree fully with the issue you are discussing. However I have seen developers get over the complexity rather quickly (e.g. Developers get comfortable making sure they write the xml correctly for hibernate within 2 weeks assuming they do not use an IDE). I have empirically observed that the number of defects is a lot lot less once the developers are comfortable with the configuration files, as is the time taken to add new functionality dealing with schema changes.
     
    > \Dhanajay Nene\
    > Simple ! Variable cost of writing persistence related code is much much lower under O-R mapped scenarios than otherwise. Its the fixed cost of learning O-R mapping, and understanding the tool (and delving into its guts at times) thats expensive. It would be very hard for me to understand scenarios where the variable cost of writing persistence code is higher for O-R mapped scenarios cos I've never seen that happen. YMMV
    > \Dhananjay Nene\
    \Mike\
    > This isn't even close to being true, if you consider it from a real working perspective. You're just trading code size/complexity for configuration complexity. Managing a system with 500 tables is going to be _lots_ more difficult than managing one with 50 tables - whether you're using an O/R tool or doing it yourself. If you believe otherwise...well, then we've obviously worked on very, very different sorts of systems. In my experience, as your total app size goes up, the "bang" you get from something like an O/R mapper goes way down, and the seeming cost of rolling by hand actually doesn't increase, but decreases, because teams invariably create their own mini-frameworks to handle the complexity.
    \Mike\
    I have used different O-R mappers (5 in fact including one of my own homegrown one cranked out within a week using sed,awk and sh - 2 with C++, and 3 with java in production applications) with different projects/products with table count ranging from 25-900. I have also worked on a smaller number of projects which did not use O-R mapping. O-R mapping used to be terribly expensive till some time back and I really welcome the open source JDO implementations and hibernate which should hope to commoditise the market and make sure the commercial vendors price themselves reasonably. The only regrets I have with some of the choices I have made are the tools themselves - not O-R mapping itself. There is an implication on performance (and sometimes it may enforce some constraints on the design) and the situations where I would choose to bypass O-R mapping is if my client is not willing to take a 10-15% hit on performance in order to get a significant improvements (25-40% ... the 40% is more during the C++ days) in developer productivity. It is likely that the vendors might feel that the performance hit is overstated, and the sql/jdbc fans might feel that the productivity gains are overstated. These are my experiences and I state them to the best of my awareness... YMMV.
  67. Prohibitive cost...[ Go to top ]

    - ...changes to the schema...

    This isn't something I can debate because I have no access to your experiences. In my experience, I've watched (and have been) painted into a technologically limiting corner when using an O/R mappers. If an application is well documented, I've found that a good JDBC developer can come-in and make excellent progress in a short amount of time without having to learn an O/R mapper. If the development talent of the staff is limited, consider this: JDBC will probably be around longer than the mapping technology. Which would you rather invest in teaching your staff?

    I think if you look closely, the number of explicite tasks required for an O/R solution maps very closely to that of a straight JDBC solution, and O/R probably takes more steps in more complex cases.

    Just as at the language level, and I think you would agree, it doesn't matter what database access method one is using, there are good and bad engineers that will engineer good/bad (read: more/less maintainable) solutions no matter what the technology.

    -Variable cost of writing persistence related code is much much lower under
    -O-R mapped scenarios than otherwise.

    This is an empirical question that really depends on the quality of the engineer, and the quality of the software design at hand. Your assertion is far from a de facto standard, my friend. Assuming a quality engineer, I think you inherit the fixed cost of the learning curve, the cost of licensing (if applicable), the cost of adaptation to subsequent arbitrary releases of the framework, the cost of refactoring the entire app if the third-party goes out of business or if the open source movement becomes constipated or if the open source movers are thieves of some kind and a lawsuit becomes pending, and the runtime and performance cost (potential and realized) of a third-party software. That's a lot of risk when JDBC is sitting and waiting, ready to be plucked like a ripe melon.

    There is a lot of effort and risk required, IMHO, to use a third party O/R or JDO implementation instead of a straight JDBC approach that just can't be justified by any sane ROI analysis.

    Just my 2c.

    John C. Dale
    DITD
  68. Prohibitive cost...[ Go to top ]

    There is a lot of effort and risk required, IMHO, to use a third party O/R or JDO implementation instead of a straight JDBC approach that just can't be justified by any sane ROI analysis.

    >


    Actually, it is riskier to use straight JDBC. Tool generated JDO classes and mapping is much more reliable and easier to maintain than any hand coded JDBC implementation.

    Just my experience.
  69. Prohibitive cost...[ Go to top ]

    \English\

    Actually, it is riskier to use straight JDBC. Tool generated JDO classes and mapping is much more reliable and easier to maintain than any hand coded JDBC implementation.

    \English\

    If you actually know JDBC & SQL, you make an effort to break your SQL into components (like select-head, finder where clauses, etc), you keep your SQL out of your code, and you use a simple light weight framework to automate a bit of the JDBC grunt work, then JDBC is very reliable, very fast, and quite easy to maintain.

    Most of the complaints I've seen around using plain old JDBC have had real root causes in:

       - no DBA on the project
       - minimal understanding of SQL by team members
       - no framework for making JDBC easier for your project - just raw JDBC
       - no organization/componentization of SQL. The almost-same SQL is repeated again and again
       - SQL is embedded in the code

    In short, a surprising number of people, when they "just use" JDBC, use it in the worst possible, and most naive manner they can. They then compare that to something like JDO and say how hard JDBC was in comparison.

    I've been on a number of projects where nobody even put indexes on any of the tables!

    Before people get down on JDBC, they should actually use it in an agressive manner first, componentize everything to avoid redundancy, and create frameworks/utility classes to use JDBC efficiently. After that, then tell me that it's just too hard.

         -Mike
  70. Prohibitive cost...[ Go to top ]

    /Spille/
    >
    > Before people get down on JDBC, they should actually use it in an agressive manner first, componentize everything to avoid redundancy, and create frameworks/utility classes to use JDBC efficiently. After that, then tell me that it's just too hard.
    >
    >      -Mike
    /Spille/

    The problem with hand coded JDBC is that if the database changes, your hand coded JDBC statements that are out of synch with the database is not picked up as an error at compilation time.

    Whereas if you use JDO and tool generated classes and mapping, the resulting classes is guaranteed to be in synch with the database. Code calling the JDO that became obsolete due to a change in the database would be caught as a compilation error at compile time.
  71. Scalability[ Go to top ]

    While I would agree that with the addition of a code generation tool, 'straight' database access via DAO is quick to develop and simple
    to maintain, how do you get around the problem of being tied to the scalability
    of your database? Custom built middle-tier cache?

    I'm much happier having to scale the middle tier solution as the need arises, and do away with the need to purchase and maintain expensive database clustering solutions, but maybe it's just me :-)

    Cheers,

    Matt
  72. Scalability[ Go to top ]

    \Jenkins\

    [...] how do you get around the problem of being tied to the scalability
    of your database? Custom built middle-tier cache?

    \Jenkins\

    In my experience, databases scale better than most Java middle tier solutions. After all, they've been designed for scalability for literally decades. It's very common to put your RDBMS on a fairly big box, and then your app server on a relatively modest box (or a cluster of them). This has been proven to scale.

    The problem is that alot of Java developers confuse response time to a single query with scalability. They throw some bad SQL at a database, see that it takes, say, 500 milliseconds to execute, and instantly look for a caching solution. What they don't realize is:

       1) databases are really good at giving consistent response times to both single users and hundreds of users.

       2) It's easier to tune SQL then get a cache right :-)

    I will throw a cache at certain types of data, and see a corresponding improvement in the overall system. But many people seem to confuse scalability and response time - caching doesn't necessarily change your scalability at all, more often it lowers your response time (which is a different beast altogether).

    I also tend to work with applications that have "god users" which routinely churn through alot of data for analysis purposes (like the head of a trading desk watching everyone's positions). In those sorts of situations, most caching products crap out - they cache thrash. An RDBMS usually handles the load much better.

    In my current gig, we will eventually have tens of app servers hitting a (very small, numerically) RDBMS cluster. The cluster is running on some monster hardware, to be sure, but empirical tests have shown that the app server won't go above around 60 TPS. The database, on the otherhand, handles several hundred TPS without a complaint.

    In a nutshell, the RDBMS is using resources overall _far_ more efficiently than the app server is. And experiments with caching has shown that they haven't helped scalability at all (but in special cases they do help with lowering average response times).

    Sadly, most of the "common knowledge" about performance is a developer running a 10-user test from his PC, measuring average response times, and then declaring a result. Real performance analysis is _alot_ more tough than that.

         -Mike
  73. Clustered JDBC[ Go to top ]

    <quote>
    ...to maintain, how do you get around the problem of being tied to the scalability
    of your database?
    </quote>

    Not anymore. Check out C-JDBC (Clustered JDBC) - an Open Source project LGPL from ObjectWeb http://c-jdbc.objectweb.org/ - and help them to improve that product. The dream to have clustered web container (Tomcat, Enhydra), clustered ejb container (JOnAS, JBoss) and clustered dbms (C-JDBC) - with all Open Source products - is becoming very real.

    Lofi.
    http://openuss.sourceforge.net
    Open Source J2EE eLearning system
  74. Clustered JDBC[ Go to top ]

    Lofi: Not anymore. Check out C-JDBC (Clustered JDBC) - an Open Source project LGPL from ObjectWeb http://c-jdbc.objectweb.org/ - and help them to improve that product. The dream to have ... clustered dbms (C-JDBC) - with all Open Source products - is becoming very real.

    C-JDBC is interesting, but it's not clustered JDBC.

    Right now, the choices are Oracle RAC, IBM federated DB2, and Microsoft clustered (limited) and/or federated SQL Server.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  75. C-JDBC[ Go to top ]

    <quote>
    Right now, the choices are Oracle RAC, IBM federated DB2, and Microsoft clustered (limited) and/or federated SQL Server.
    </quote>

    yes (http://c-jdbc.objectweb.org/doc/index.html). I'm going to try C-JDBC in our production system soon. At the moment the only single point of failure is the database (Firebird).

    At the moment we have:
    - Enhydra (Servlet Container) load balanced with Apache and Director,
    - JOnAS (EJB Container) not yet load balanced, waiting for the 3.2 version, which will include load balancing. Very soon.
    - Firebird. Not load balanced. I'm going to put C-JDBC on the top to load balance the Database.

    So, I think, C-JDBC would be a great stuff to help Open Source databases to scale.

    Best regards,
    Lofi.
    http://openuss.sourceforge.net
  76. Just found this paraphrase by Cameron Purdy of Bruce Tate (author of Bitter EJB) from the TSS Symposium "His next point is that 50-60% of applications should not even consider using a persistence framework, and that they should use JDBC to access the database directly. He doesn't feel that these applications need to work with the data in an "object form", and that the relational model (maybe with POJOs at the most on top of it) is sufficient. He points out that this does break down, though, when you shift from thinking about the relational world to thinking about the object world. When it does break down, you are going to have to pay a price (including performance) to move (bridge) between these two world. He talks about the downside of the frameworks for doing the bridging, and mentions clustering again, because "you can't cluster POJOs" or something like that (argh!) "
  77. Just found this paraphrase by Cameron Purdy of Bruce Tate (author of Bitter EJB) from the TSS Symposium "His next point is that 50-60% of applications should not even consider using a persistence framework, and that they should use JDBC to access the database directly. He doesn't feel that these applications need to work with the data in an "object form", and that the relational model (maybe with POJOs at the most on top of it) is sufficient. He points out that this does break down, though, when you shift from thinking about the relational world to thinking about the object world. When it does break down, you are going to have to pay a price (including performance) to move (bridge) between these two world. He talks about the downside of the frameworks for doing the bridging, and mentions clustering again, because "you can't cluster POJOs" or something like that (argh!) "


    Can't cluster POJOs???? BAHAHAHAHA!!!! JBoss 4 can cluster POJOs.
  78. Bill: Can't cluster POJOs???? BAHAHAHAHA!!!! JBoss 4 can cluster POJOs.

    Any Java app can cluster POJO's with Coherence ... that was what my "Argh!" meant ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  79. On the issue of caching...[ Go to top ]

    RDMS can scale as well. How do O/R mappers handle listing large number of entities?

    List contactList = contactDao.findAll();
    Iterator i = contactList.iterator();
    while(i.hasNext()){
      Contact contact = (Address) i.next();
      out.println("First name: " + contact.getFirstName());
      out.println("Last name: " + contact.getLastName());
      out.println("Email: " + contact.getEmailAddress());
    }

    AFAIK, this requires something like so:

    List contactList = new ArrayList();
    ResultSet rs = stat.executeQuery();
    while(rs.next()){
      Contact contact = new Contact();
      contact.setFirstName(rs.getString("first_name"));
      contact.setLastName(rs.getString("last_name"));
      contact.setEmailAddress(rs.getString("email"));
      contactList.add(contact);
    }
    return contactList;

    The creating and then destroying of large numbers of objects will hamper performance AFAIK. Caching can avoid this problems, however if the data is changing then the cache may decrease performance (especially in a distributed cache).

    Scaling the database may not be practical when using expensive commerical databases, that is why I use postgres. Then to overcome a bottleneck in the database I can add nodes to the database cluster. Much simpler and cheaper then caching at the application server. Although you avoid the network with application caches. However, it seems to me that CPU is the main bottleneck (just look at rubis).

    In regards to PetStore, I haven't notice anyone suggest generating static pages for the product catalog. Whenever a product changes you just have that page be generated and replace the existing page, since changes in the catalog are not very frequent (compared to the browsing of the catalog).
  80. On the issue of caching...[ Go to top ]

    There are also caching JDBC drivers available (to scale the RDMS without increasing the database tier). Refer to
    http://www.theserverside.com//home/thread.jsp?thread_id=20180&article_count=1
  81. Is DAO Pattern worth it?[ Go to top ]

    An important question to ask yourself when answering this question is: What is the cost/benefit ratio?

    With DAO (and other such persistence patterns) the main benefit is to be able to change the datasource without affecting the business logic. The problem with using JDBC directly is that you have to change the business layer if you change from a RDMS to an OODBMS.

    I would like to point out:
    The cost of building flexibility must be cheaper then the cost of changing the code the flexibility is protecting. The flexibility must also accommodate the changes and this is difficult to achieve. You may find that your assumptions are wrong and then the flexibility does not hold up and changes to the code must be made anyway. Although this may be less then if you didn't build in the flexibility it has to be factored into the
    consideration.

    In other words does the cost of the DAO pattern outweight the benefit it provides? IMO it does not. Consider the following query from an online shopping site:
    select orders.order_id as order_id, order_date, sum(item_price * quantity) as total
    from orders,lineitem
    where username=? and orders.order_id = lineitem.order_id
    group by orders.order_id

    In OO modeling the above would be implemented with a getTotal method:
    public class Order{
      public double getTotal(){
        double total = 0;
        Iterator i = getLineItems().iterator();
        while(i.hasNext()){
          LineItem item = (LineItem) i.next();
          total += item.getSubTotal();
        }
        return total;
      }
      //...
    }

    public class LineItem{
      public double getSubTotal(){
        return getQuantity() * getPrice();
      }
      //...
    }

    However this is more complex and more code then the SQL approach. Also queries such as:
    select product.product_id as product_id, product.name as product_name,
           item.description as item_name, item_price, quantity
    from lineitem,item,product
    where order_id=? and lineitem.item_id = item.item_id
          and item.product_id = product.product_id";

    result in code like:
    Iterator i = order.getLineItems().iterator();
    while(i.hasNext()){
      LineItem item = (LineItem) i.next();
      out.println("Product id: " + item.getProduct().getProductId());
      out.println("Product name: " + item.getProduct().getName());
      out.println("Description: " + item.getDescription());
      out.println("Price: " + item.getPrice());
      out.println("Quantity: " + item.getQuantity());
    }

    Notice the item.getProduct().getProductName() . This is not a problem as long as the object graph doesn't change (which it should for this application).

    In summary, I guess the issue of which is the better approach is subjective. Changing RDMS doesn't seem likely to me let alone changing the paradigm for data storage. Changing RDMS can be handled with specifing the SQL in an external file. When using JDBC (although not perfect) it can reduce the amount of code and is easier to maintain. In other words, I feel the cost of the DAO pattern or other such abstractions of the datasource are not worth the hassles.
  82. Notice the item.getProduct().getProductName() . This is not a problem as long as the object graph doesn't change (which it should for this application).


    I meant to say the object graph is unlikely to change (at least for the online shopping application).
  83. JBoss new architecture[ Go to top ]

    Hi,everyone!

    I think, may be wrong, that architecture of JBoss can be like that:

       
       JDO/Pojo EJB/Cmp
         \ /
         
        AOP/other mechanism
        for introspection
               |
        Persistence Layer

    Why i decide to write it - bacause i afraid that JDO & EJB persistence layers
    may be separated by development team, that can make more difficult to support
    it.Persistence layer must be like Hibernate and supports different
    database dialects.

    Bye.
  84. I'm really glad JBoss has the courage to break away from the J2EE profit machine. The majority of developers who've used both JDO & CMP agree that JDO is a much better solution for the majority of projects. I really think BEA & IBM missed the boat with JDO, and SUN covers for them by hiding JDO in the closet and pushing EJB. WebLogic & WebSphere cost thousands per CPU. This insane pricing cannot go on forever. Along comes JBoss. Now that they've gotten a large J2EE marketshare, they've got the guts to quit following SUN's marketing propoganda. They've not only give people a free alternative to insanely priced application servers, they've also given developers a free alternative to insanely complicated frameworks! Someone said this is not good for J2EE but I totally disagree. Profit-driven greed is what's not good for J2EE. I applaud JBoss for being technology driven instead of profit driven.

    For Dale, it sounds like you really don't understand JDO and that you're just against new technology in general. I think you owe it to yourself to download a JDO implementation and try a tutorial to get an idea of what JDO really is all about. Kodo has a trial version which comes with an excellent tutorial, takes less than 1 hour to learn the basic concepts and play with the code.

    Michael Mattox
  85. Michael,

    I think profits are good. My profits.
    If I pay vendors $, I am not profitable. But if I keep my costs low and value high.... good.

    Open source, to me, is sofware FOR profit.

    .V
  86. JDO is not practical or it would be pervasive by now.

    After some work, it may become more practical. At that time, I'll consider taking another look.

    Until then, or until I fail with my current approach, I'll stick with what I know.

    I know SQL to database will scale to 1291 concurrent users per cluster node without degredation in performance. Much of that throughput results from entity tier caching. Much of it results from the fact that I don't let a third party into my system that creates millions of transient objects, and I do short-lived, vanilla database dings.

    Best,

    John C. Dale
    CEO, Chief Architect
    Down in the Desert
  87. Maybe you can try ObjectStore (if you can life with its bugs).
    No mapping is required.
  88. Timeshare anyone???[ Go to top ]

    Why does this remind me of a spa membership proposal...

    I owe it to myself?

    ;)

    John C. Dale
    DITD
  89. ejb vs non ejb[ Go to top ]

    Floyd it doe snto matter to the custoemr whether ejb o rnon ejb..

    They want soemthing that works in theri situation..

    choosing JDO does in no way decrease the value of ejb in JBoss app servers..

    Both ejeb and non ejb soultions are choosen for different reasons..

    to imply otherwsie is idiotic and vendor FUD..
  90. I had my first experience with JDO in the last 3 months. My app has a web interface that schedules jobs to run batchs for processing entries more than 1 GB size and store then in the database. The application uses JDO to store data in the database. Its fast, easy and clean. This application runs in Solaris / Weblogic and, Oracle as database in a government institution.

    My JDO implementation provides 2 level of cache, and to implement my app, I did think more on business then spending time to create a DAO layer in the Business tier.

    To help me, I think, there could be a book on JDO best practices showing me the right way to do things with JDO.

    Today, if I can choose between EJB or JDO, I certainly choose JDO.

    Thats my success case with JDO.
  91. EJB vs. JDO a false dichotomy...[ Go to top ]

    If we can't agree that EJB is a good thing, then we don't have much to talk about. Over time, as you development experience increases, you'll find that the transaction and caching management provided in the SUN specification are wonderful things. There is great return in using them.

    JDO vs EJB I think not.

    JDO vs vanilly CMP maybe.

    JDO as a CMP implementation VERY LIKELY.

    Best,

    John C. Dale
    CEO, Chief Architect
    Down in the Desert, Inc.
  92. http://www.downinthedesert.com/nav.ditd?nav.destination=JohnCDaleResume
  93. What I wish JBoss would do...[ Go to top ]

    I think there is more of an advantage for the JBoss group to make clustering more straight forward, to stabilize their HTTP server (I have sporadic problems with the HTTP context blowing chow even with the latest version), with the management interface.

    Generally speaking, a 6-12 month effort to harden and improve the existing codebase and management interfaces would be VERY well wortht the effort.

    JMHO.

    Best,

    John C. Dale
    CEO, Founder
    Down in the Desert, Inc.
  94. .foobar..
  95. POJO[ Go to top ]

    Just coming in on this thread a bit late. Just want to agree with the point that JDO allows you to do designs in terms of java objects. Not tables. Not Entitites. One big annoyance with CMP was that I had to write a separate finder method for each subclass I was trying to retrieve from the database, and execute N finder methods at run time to get all the subclasses.

     In many application areas, like Geographic Information Systems, you just can't get around deep inheritence hierarchies, because the data model is fundamentally complex. And a deep/rich hierarchy of persistent objects is just totally at odds with CMP. JDO on the other hand just makes sense for object-oriented designs. It encourages you to use all the OO techniques, all the way down to persistence. With CMP, I sort of felt like my wonderful OO design was a veneer because I had to do all these ugly contortions at the persistence layer.

    I also like JDO's freedom from hords of deployment descriptors and EAR files. For most web apps, JDO from the web tier is fine. You wind up with far cleaner business objects using JDO because you can make a good POJO design. How many web apps really need a distributed transaction? If you need a distributed transaction, obviously EJB is great. Personally I would just write a stateless session bean to encapsulate my JDO.

    -geoff
  96. POJO[ Go to top ]

    \hendrey\
     With CMP, I sort of felt like my wonderful OO design was a veneer because I had to do all these ugly contortions at the persistence layer.
    \hendrey\

    Leaving CMP out of it for a moment, there's a fundamental problem with your statements: an RDBMS is not OO. It'd be really, really nice to have a fully OO system with rich object graphs _and_ have such a system's persistence layer be really fast as well. But the OO database people have already proved that what's good for modelling in-memory objects is _not_ good for modelling persistence. It's not fast enough, and OO graphs are just too dynamic.

    For your application, you might not care. JDO, or some other similar solution, may be fast enough. But for many of us, it's not fast enough, and the reason why is that OO models don't fit real well into rows and columns, and to make them fit so that the database is small enough, fast enough, and easy enough to maintain means some deep thought and making some tough decisions, and taking on more responsibility for what's happening at the Object<-->persistence interface point.

    As I said, you may not care. Indeed, many developers literally do not know (and don't want to know) anything about RDBMS systems. If their systems work well enough, great. But all too often they rely too heavy for some framework to do the work for them, and then run into some very ugly maintenance and performance problems because they abdicated a big chunk of their responsibility.

    People may not like SQL and JDBC - it's not OO, it's not cool, it's not new, it's foreign to the "java way" that they've learned. But the fact remains that they are very, very good at getting data into and out of a database, and far too many developers ignore that fact - and have it bite 'em in the ass down the road.

    As a side note - creating finder methods is hardly a difficult task, and I'm a bit surprised that you'd let someone automate it, because finders are exactly one of those things in RDBMS systems that tend to contain the biggest performance problems. That, and well - real databases have real deadlock problems, and I'd want to make sure to the best of my ability that my SQL isn't going to deadlock the world when it's put under load. But I'm sure someone will tell me that JDO has solved that problem and is deadlock-free :-)

        -Mike
  97. Again, nice response...[ Go to top ]

    It had practicality written all over it.

    "...abdicated a big chunk of their responsibility..."

    Couldn't agree more.

    I would say, though, that it's tough to pin-down OO. I think JDBC and SQL are definitely object-oriented approaches...Connection, ResultSet, PreparedStatement. All objects that cohesively encapsulate state and behavior. It's not perfect, but is proven in the face of stringent scalability and performance requirements.

    Consider this:
    select firstname, middlename, lastname from person where id = 'someId'

    Our table, person, encapsulates a person's attributes. This feels very OO to me.

    Lastly, love your comments about a system under load. Until you bombard your application with requests of all types from multiple threads, you'll never know if you've made the right decision in the persistence tier. Rubber meet road. When we used them, Versant and Gemstone PCA both had horrid problems with deadlocks that even their consultants had a hard-time explaining away and/or figuring out.

    Prost!

    John C. Dale
    DITD
  98. AAARRRGGGHHH!!![ Go to top ]

    It had practicality written all over it.

    >
    > "...abdicated a big chunk of their responsibility..."
    >
    > Couldn't agree more.
    >
    > I would say, though, that it's tough to pin-down OO. I think JDBC and SQL are definitely object-oriented approaches...Connection, ResultSet, PreparedStatement. All objects that cohesively encapsulate state and behavior. It's not perfect, but is proven in the face of stringent scalability and performance requirements.

    It is far from perfect and we all know it. JDBC is the best low-level solution we have to the impedance between relational data and objects. It is not a cohesive solution by any stretch of the imagination. It's only proven in "the face of stringent scalability and performance requirements" because there's nothing else to compare it to.
    Cohesive encapsulation? You're talking about having to know and understand and be comfartable with upwards of a dozen interfaces and classes. There are currently 3 releases of the JDBC specification in use, with another is the works, all with a large amount of optional material. And to top it all off there's this stupid java.sql.Date extension of Date to provide an endless source of amusement for JDBC developers attempting to persist data.
    It may be OO but it's not good OO.
    Frankly - bits of JDBC suck big time ;)

    >
    > Consider this:
    > select firstname, middlename, lastname from person where id = 'someId'
    >
    > Our table, person, encapsulates a person's attributes. This feels very OO to me.
    >

    NO! NO! NO! If this feels "OO" to you then something is very seriously amiss. It encapsulates the person's attributes sure. But there is no functionality. There is no behaviour. These are somewhere else. So where's the encapsulation? All you're talking about here is data. This is data. This is not OO.
    Three columns of data from a database table is not OO it is data.
    I've been reading following your anti-JDO thread for a few days now with interest. Although I strongly disagree with your arguments you've been providing a hugely enjoyable and highly literate opposition to JDO. Possibly ill-guided but intelligent nontheless :)
    Don't ruin it with a comment that can be summarized as "Data in RDBMS is object-oriented". It is not and hopefully everyone here knows that.
     
    s

    > Lastly, love your comments about a system under load. Until you bombard your application with requests of all types from multiple threads, you'll never know if you've made the right decision in the persistence tier. Rubber meet road. When we used them, Versant and Gemstone PCA both had horrid problems with deadlocks that even their consultants had a hard-time explaining away and/or figuring out.
    >
    > Prost!
    >
    > John C. Dale
    > DITD
  99. RE: AAARRRGGGHHH!!![ Go to top ]

    The problem with persisting dates is that java.util.Date represents a Date and Time. So java.sql.Date wraps java.util.Date to represent just a Date (SQL date)to the JDBC driver. Another thing that I find annoying is working with BigDecimal (NUMERIC SQL type). I wish operator overload was builtin for the math classes (Integer, Double, etc.).

    Below is an extract of using the JDBC approach (order processing for online shopping site):
    String username = (String) request.getSession().getAttribute("user");
    int cartId = ((Integer) request.getSession().getAttribute("cart")).intValue();
    int orderId = 0;

    Connection conn = null;
    try{
      // insert order
      conn = DbHelper.getConnection();
      PreparedStatement stat = conn.prepareStatement(INSERT_ORDER);
      orderId = sequenceGenerator.getNextId("order");
      stat.setInt(1, orderId);
      stat.setString(2, username);
      stat.setTimestamp(3, new java.sql.Timestamp(Calendar.getInstance()
    .getTime().getTime()));
      stat.setString(4, (String)orderMap.get("shipping_street"));
      stat.setString(5, (String)orderMap.get("shipping_city"));
      stat.setString(6, (String)orderMap.get("shipping_state"));
      stat.setString(7, (String)orderMap.get("shipping_postcode"));
      stat.setString(8, (String)orderMap.get("billing_street"));
      stat.setString(9, (String)orderMap.get("billing_city"));
      stat.setString(10, (String)orderMap.get("billing_state"));
      stat.setString(11, (String)orderMap.get("billing_postcode"));
      stat.setString(12, (String)orderMap.get("billing_firstname"));
      stat.setString(13, (String)orderMap.get("billing_lastname"));
      stat.setString(14, (String)orderMap.get("shipping_firstname"));
      stat.setString(15, (String)orderMap.get("shipping_lastname"));
      stat.executeUpdate();
      stat.close();

      // insert lineitems
      stat = conn.prepareStatement(GET_CART_ITEMS);
      stat.setInt(1, cartId);
      ResultSet cartItems = stat.executeQuery();
      PreparedStatement insertLineItem = conn.prepareStatement(INSERT_LINEITEM);
      while(cartItems.next()){
        insertLineItem.setInt(1, orderId);
        insertLineItem.setInt(2, cartItems.getInt("item_id"));
        insertLineItem.setInt(3, cartItems.getInt("quantity"));
        insertLineItem.setBigDecimal(4, cartItems.getBigDecimal("price"));
        insertLineItem.executeUpdate();
      }
      insertLineItem.close();
      stat.close();

      // clear shopping cart
      stat = conn.prepareStatement(REMOVE_CART);
      stat.setInt(1, cartId);
      stat.executeUpdate();
      stat.close();
      stat = conn.prepareStatement(REMOVE_CART_ITEMS);
      stat.setInt(1, cartId);
      stat.executeUpdate();
      stat.close();
      conn.commit();
      conn.close();
      request.getSession().removeAttribute("cart"); // delete cart from session

      // clear order from session
      request.getSession().removeAttribute("order");
    }catch(Exception e){
      try{
        if(conn != null){
          conn.rollback();
          conn.close();
        }
      }catch(SQLException err){ /* ignore */ }
      e.printStackTrace();
    }

    // view order
    response.sendRedirect("ViewOrder?order_id=" + orderId);


    AFAICT this code should port to different RDMS. If we want to optimise the converting of the cart items to order line items (MySQL has INSERT INTO...SELECT syntax) then we can factor that out.

    public interface CreateLineItemsFromCart{
      public void setCartId(int cart_id);

      public void setOrderId(int order_id);

      public void execute();
    }

    As for seperation of concerns (JDBC code is mixed with business logic in the above code) you can use the Data Access Command pattern. However considering that the above persistence logic is only used by the order processing it seems overkill. Although DAC pattern will add compile-time checking between the business logic and persistence logic.

    I'm still working on what is better for maintainability. I'm implementing the online shopping site using different patterns for persistence and seeing which approach requires the least changes.

    BTW, I'm going to extend PreparedStatement to allow for named and typed parameters (using an XML config file) to avoid errors in parameter setting. So

      PreparedStatement stat = conn.prepareStatement(INSERT_ORDER);
      orderId = sequenceGenerator.getNextId("order");
      stat.setInt(1, orderId);
      stat.setString(2, username);

    becomes

      ParamStatement stat = DbHelper.createStatement("insert_order");
      orderId = sequenceGenerator.getNextId("order");
      // stat.set(...) throws an exception if the parameter is of wrong type
      // or the parameter does not exist
      stat.set("order_id", orderId);
      stat.set("username", username);
  100. Hopefully, you won't have incredibly stringent concurrency requirements.

    There are an infinity of ways to solve very complex problems with OO. A good rule of thumb is that if you are more than 3 levels deep in your inheritance hierarchy, you've likely misapplied OO. Trying to track down which method was called from which parent under what circumstance can be tricky. K.I.S.S. I cannot appeal to that concept enough. Simple, thoughtful, elegant; all properties of a good software solution.

    Best,

    John C. Dale
  101. Portability of JBoss JDO[ Go to top ]

    I recall the time when Marc preferred EBJ2.0 to JDO in an article "JBoss Founder Marc Fleury: Why I love EJBs "

    I had given my opinion concerning this issue in the thread

    http://www.theserverside.com/home/thread.jsp?thread_id=16834&article_count=155#67372

    And I believe it's really a good think that Jboss Group have chosen to implement JDO.

    But is JBoss JDO usable in Websphere or Weblogic ? I mean without modifiying and recompiling the code ? (I mean using JBoss JDO as a persistence layer in sessions beans deployed in Weblogic for example)

    This is important, even if your preferred app server is JBoss that might not be the case of one of your client (in the perspective of an ISV)

    Another question : When will we be able do download JBoss JDO as a separate composant (without JBoss), I have tried to compile what I got from CVS and I needed many things from JDO core binaries, and I did not achieve my goal since I did not what version of JBoss to refer to in my lib.

    I prefer, if I used JBoss JDO in the developpement process, to test my applications on a another app server (Websphere, for example, is more strict concerning remoteness and passing object by value, weblogic may pass some objects by ref even when calling a remote method - for performance reasons they say - so multi app servers testing is important since behaviour is not the same).

    Is there a way to have JBoss JDO as a USABLE SEPERATE package ?

    Or where can I find instructions for compiling the CVS project to generate a separate JDO jar to use like I hope to.

    Thank's





    Gabriel
  102. JDO vs CMP Entity Beans[ Go to top ]

    Hi,

    I have been working on J2EE technogies since last few years, but I am pretty new to JDO. I have been going thru some articles and of course this forum to get familiar with the whole concept. What I understand is, the developers try to avoid CMP entity beans because of performance issues. But since, EJB 2.1 supports local interface, there is a tremondous performance improvement. A good application server's optimization capabilities would help to improve the performance as well. So why one should use JDO instead of Entity CMP local interfaces?

    Once more time, I am just trying to understand the benefits of JDO over CMP beans in terms of performace.

    Any reply will be kindly appreciated.

    Sachin
  103. JDO and EJB[ Go to top ]

    For sure EJB 2.O bring more preformance and flexiblity to entity beans :

    -Local interfaces give you a access by reference to the bean
    -Finder are optimized
    -Relation have been added (accessed throught local interfaces, related objects must be located on the same server)
    -EJBQL has been added
    -Setter are abstract, that give more optimisation possiblities to the EJB persitance and caching mechanisms.
    etc...

    But still they have some drawbacks compared to JDO, perhaps not of performances (performance depends on JDO and EJB verdors).

    Disadvantages of EJB 2.0:
    -Multi application servers deployment (you will need to maintain differents deployment descriptors for the mapping between entities and relational tables - this can be automated using XDoclet - still you need to use it correctly - It's already difficult to check that minimal documentation is added to all code and since XDoclet is a sort of extra doucmentation, you cannot check it untill you deploy on all the targeted app servers, it automates the task but it does not garantee the results)
    ejb-xml is not enough (http://www.theserverside.com/home/thread.jsp?thread_id=16834&article_count=155#67413)
    -JDO is easier to use (no LocalHome Local Remote and Home interfaces to maintain - you need at least LocalHome + Local + the Bean Implementation)
    -Since it's recommended not to access Entities remotely (Session Facade Pattern) So wy bother and use entities
    -JDO is more flexible and usable and object oriented.
    etc..


    In the previous post found here

    http://www.theserverside.com/home/thread.jsp?thread_id=16834&article_count=155#67372

    you will find more details about this ...

    Best regards

    Gabriel