TopLink: 10 Years of Persistence

Home

News: TopLink: 10 Years of Persistence

  1. TopLink: 10 Years of Persistence (61 messages)

    The two Oracle people interviewed by TheServerSide are Mike Keith and Doug Clarke.

    Mike Keith has over 15 years of teaching, research and practical experience in object-based and object-oriented systems, specializing in object persistence. He has a Master’s degree in computing, specializing in distributed persistent object systems and has spoken previously at JavaOne and other conferences. He is an architect for Oracle’s TopLink product and represents Oracle on the EJB 3.0 expert group.

    Doug Clarke is a principal product manager for Oracle TopLink. Doug also has extensive consulting and educational field experience focusing on persistence projects including object-relational and other architectures. He brings together a decade of experiences of customers and projects from around the world and includes small “dot-com” through to Fortune 500 companies. Doug is a frequent speaker at Java conferences around the world.

    1. How does Oracle TopLink fit in to the combination of JDO and EJB3 persistence?

    Mike: Just to clarify, JDO and EJB persistence are not being combined. A number of the JDO experts have been added to the EJB expert group. The EJB 3.0 spec has continued from the draft we previewed back in June. That being said, a new group of people will bring new ideas, so I do expect the EJB spec to evolve and benefit from this addition. It certainly is much better for J2EE to have clarity and a single specification for persistence.

    TopLink fits very well with the direction of the EJB spec. Today, we have a unique solution in that we support both POJOs and Entity Beans using the same underlying persistence engine and developer tools. In fact you can use them both together and have Entity Beans reference POJOs using TopLink CMP. The direction towards a lightweight POJO-based persistence model for EJB works well for our customers as they will be able to leverage the technology they are using today and also have the protection of conforming to a widely supported industry standard.
      

    2. What work is Oracle doing on the EJB3 JSR?

    Mike: We are strong supporters of JSR 220 and believe that this will be the very best Java persistence specification to date. We are firm in this commitment because we believe that the new direction of EJB is going to help cement it as the preferred platform for enterprise Java development and deployment.

    I have personally been given the go-ahead to contribute whatever time is needed to further the specification and have been spending a great deal of my own time putting together proposals and responding to proposals from others. The nitty-gritty details of O/R mapping, annotations, queries, callbacks/interceptors, and the like takes a lot of time to work out. I really like working on this stuff and have thoroughly enjoyed contributing to the spec. I have a huge amount of respect and admiration for Linda and the other expert group reps and have built up friendships that will last beyond the specification itself. Because of this dynamic I believe that we are all way more productive as a group.

    We are also getting the word out about the changes in EJB 3.0 because some people have already discarded it for its previous deficiencies. After hearing about the new direction of EJB persistence these are the people that are the most excited about trying out EJB3, so our goal is to carry the message to as many people as possible and woo some of these disillusioned people back to a smaller, lighter and faster EJB.

    3. What is Oracle's vision for persistence post EJB3?

    Doug: Persistence is growing in many areas and EJB3 is just one aspect. By all accounts it is overdue as a lightweight persistent Java object specification and standard for O/R mapping. Developers are looking to EJB3 to solve the problems that they are having right now.

    Beyond EJB3, TopLink continues to innovate in the ORM space as our customers express their needs in this area. Some examples include data partitioning to work with Virtual Private Database solutions, XML Database mapping of XML Type columns, mapping of historical data for point in time queries and automatic versioning of data during modifications, and runtime management of the persistence layer through JMX.
     
    Persistence solutions also need to expand beyond relational data to formats such as XML and to integrate the many non-relational data stores enterprises also must leverage. In our latest version, we have introduced object-XML (JAXB) capabilities, providing similar mapping flexibility and runtime features that people have come to expect with object-relational solutions. The emergence of Web services and SOA has added new dimensions and persistence will evolve from point O/R solutions to broader data integration solutions.


    4. Who is using TopLink in a substantial way?

    Doug: Our install base ranges from the startup to the enterprise. Blue chip companies like Schwab, Fed Ex, and BMW. Defense companies like Northrop Grumman and bio tech companies like Curagen and Millennium. Over the years we’ve helped countless startups, one recent example that is big on the “cool” factor is shazam.com.

    TopLink is very pervasive and is used in a wide variety of applications. If you’ve ever shipped a package, received a paycheck, ordered flowers online or had a phone bill, there’s a good chance that TopLink had a part to play in that process.

    The common thread among our users is they seek a proven solution with a low risk future. Many of our customers have seen technologies and programming styles change over the years, and TopLink has always adapted to these changes.

    5. If I deploy TopLink in a clustered application server environment, will it work? Does it keep any cached data synchronized? If so, how? Are there any limitations? Will this work with clusters of non-Oracle application servers?

    Mike: Clustering strategies have been on our radar and part of the TopLink product since mid-tier clusters first started being deployed. We have grown with the industry, as clustered data became more of a standard practice than an exception, and have a number of options including automatic cached data propagation as well as locking and refreshing API calls for users that want more explicit control when they run in clustered environments.

    In our current version we are offering even more choice in terms of how data can be coordinated between clustered caches. We provide both data invalidation as well as content propagation at a more fine-grained class level. People seem to be quite enthusiastic about our clustering solutions, and our new release recognizes the needs of all applications on the read/write spectrum, from read-only and read-mostly to read/write and write-mostly applications.

    TopLink has always been easy to plug into any compliant application server that follows transaction and connection standards, and has been adopted by companies using virtually every major server on the market. Because of this, heterogeneous application servers can very easily be clustered together using TopLink as a caching backbone, as well as providing normalized support for every major database on the back end!


    6. How does TopLink deal with the overall complexity of object-relational mapping? Can mere mortals be productive with TopLink or do you need to be an expert in object-relational mapping?
     
    Doug: TopLink provides an environment where developers with varying degrees of ORM experience can be productive. ORM tools are available with the stand-alone TopLink Workbench or fully integrated with JDeveloper. Either option provides powerful graphical interfaces for mapping objects and generating the XML metadata, however they go even further by actually assisting the developer during the mapping process. Along with managing the complicated dependencies between the objects and mappings, the tools also flag any mapping issues and offer hints and advice to the developer on how to resolve them.
     
    Run-time settings can also be configured using the tools. These settings include query definitions, event management, locking, caching, platform configuration and cluster management. TopLink also provides configurable diagnostic and debugging information such as SQL tracing and logging. The rich feature set, fronted by the easy to use tools, allows both neophytes and ORM experts to be successful.

    7. Why did Oracle decide to leave the JDO group? Was it technical or political?

    Mike: I was assigned to be on the JDO expert group for JSR 243. JDO 2.0 was planning to add O/R mapping to the spec and we were invited to participate. POJO-based persistence was obviously something we believed in strongly as we’ve supported it since day 1 of our product. With EJB 3.0 also heading down this road and the specifications taking essentially different paths to solve the same problem, it was clear that we needed to make a choice. Java needs one specification covering POJO O/R mapping, not zero, and not two.

    We felt that we would be better able to communicate the needs of our existing customer base within the EJB context, especially given that we already had an established EJB clientele. Being that EJB was already part of the J2EE platform that is used by the vast majority of our installed application base I guess the decision was pretty clear. I actually enjoyed working with most of the folks in the JSR 243 group and found the majority of them to be smart and talented individuals, many of whom I still count as being friends. In fact, I have been able to work with some of them again as a few have joined the EJB 3.0 expert group to help with the persistence specification that will emerge from JSR 220.


    8. TopLink has historically been implemented using reflection type approaches. Is that still the case? Or are you doing more with bytecode now?

    Mike: TopLink has always made extensive use of reflection. We have also always claimed that execution in a reflection-based architecture is no slower than non-reflection-based products, as long as the reflection artifacts can be cached. This has proven to be true and other products have also backed this claim up. In fact anybody that does a quick benchmark of reflective method invocation or field access can see similar results.

    We don't have anything against byte-code enhancement, or products that use enhancing. We just don't think that a specification should mandate such a thing, or force a certain implementation path. Specifications should dictate APIs and semantics, not implementation. We are currently investigating using enhancement techniques to solve certain problems that cannot be solved any other way. By no means does this imply that we are changing our direction or dropping reflection as the primary means of solving the persistence problem. It may be that some features will be able to be offered to customers that want them if they are willing to accept them in this context. Given that our customers have different needs, requirements and policies we clearly don't want to force anybody in any one direction.


    9. Why would someone choose TopLink over Hibernate, or SolarMetric, or ... How are you differentiated?
     
    Mike: TopLink brings with it a strong history and long track record in this market. It is proven, scalable technology that has its feature set evolved from use by thousands of customers building challenging, diverse applications. After 10 years, we have the richest, most powerful feature set available and can address very sophisticated requirements.

    Another major differentiating factor is we offer functionality beyond a pure O/R mapping product. We provide the ability to map to XML and other types of non-relational data. TopLink brings much more to the table in terms of the complete data integration story than it ever has before. It is very exciting actually, because as we offer bigger and better solutions it also keeps it interesting for us at the development level. TopLink has proven itself as a leading and visionary product and has lead the way in O/R mapping for a decade, now. We will continue to show leadership as the problem space expands.

    10. How does TopLink fit into the Oracle world of persistence (outside of the J2EE app server)?
     
    Doug: Since Oracle acquired TopLink it has become an internal standard for persistence within the organization. A company the size of Oracle has a great many persistence needs and products that make use of persistence. Both our O-R and O-X components are being used by an increasing number of internal groups to solve the problems that used to be solved by other frameworks, so many people that use Oracle products are going to be using TopLink more and more frequently without even being aware of it! For example TopLink technology is used to provide a flexible database adapter for use with Oracle’s BPEL product.

    Oracle provides a complete Java stack, so outside of the obvious application server integration TopLink is also integrated with JDeveloper, the Application Development Framework (ADF), the BPEL database adapter, and TopLink also uniquely leverages advanced features of the Oracle database such as XDB, Virtual Private Database (VPD), and many advanced data types and queries. This integration provides a powerful, end-to-end solution for J2EE developers.

    11. Does TopLink support platforms beyond Oracle?
     
    Doug: TopLink has always supported all of the major database vendors and it always will, as the IT world is heterogeneous. We also can run on any J2EE compliant application server including Oracle OC4J, WebLogic and WebSphere and in fact can run outside of a server in J2SE. Our daily regression test suites run on those three application server platforms using Oracle, Sybase, SQL Server and DB2 as the database back ends.

    Database products are unique and TopLink provides support to allow developers to leverage proprietary features from all vendors. Being part of Oracle gives us unique access and allows us to provide the very best ORM support for the Oracle database. TopLink allows applications to take advantage of these specific database features or be built in a generic fashion and be completely portable across databases.

    Threaded Messages (61)

  2. How to write a good specification...[ Go to top ]

    We don't have anything against byte-code enhancement, or products that use enhancing. We just don't think that a specification should mandate such a thing, or force a certain implementation path.

    For reference, JDO 1.0 never mandated bytecode enhancement, but it did mandate that persistent classes implement PersistenceCapable. Bytecode enhancement, whether at build or at classload time, was deemed by most implementations to be the least invasive way of doing this since it (a) did not require effort on the part of the developer, and (2) preserved line numbers for debugging purposes.

    JDO 2.0, driven by requests from Oracle, lifts the requirement for persistent objects to implement PersistenceCapable.
    Specifications should dictate APIs and semantics, not implementation.

    JDO 2.0 does precisely this.

    For example, a detached JDO instance might deliberately not have had all of its field values loaded prior to detachment. Instead the graph of loaded fields is dictated by JDO 2.0 fetch groups. In such cases a field with Java default values (e.g. null, 0) could be (a) legitimately null or 0, or (b) not loaded. The JDO specification specifies the semantic that a detached instance must FAIL FAST if an application causes it to reference/change one of its fields that has not been loaded from the database.

    So, how do you implement such a semantic? Bytecode enhancement has proven to be the most widely chosen design choice. But the JDO 2.0 spec does not require it.
    We are currently investigating using enhancement techniques to solve certain problems that cannot be solved any other way.

    Precisely.

    Kind regards, Robin.
  3. Toplink CMP is a mixed bag...[ Go to top ]

    TopLink fits very well with the direction of the EJB spec. Today, we have a unique solution in that we support both POJOs and Entity Beans using the same underlying persistence engine and developer tools. In fact you can use them both together and have Entity Beans reference POJOs using TopLink CMP.

    As a consumer of Toplink CMP, I have had a mixed experience. Toplink enhanced CMP is a tremendous improvement over standard EJB 2 CMP, but the downside is that the interface between the app server (in our case WLS) and Toplink is proprietary and leads to maintenance nightmares. Every time WLS comes out with a service pack we run the risk that our application will break, so we are stuck in limbo until Toplink issues a corresponding patch.

    I'm hoping that EJB 3 will remedy this situation.
  4. Toplink CMP is a mixed bag...[ Go to top ]

    As a consumer of Toplink CMP, I have had a mixed experience. Toplink enhanced CMP is a tremendous improvement over standard EJB 2 CMP, but the downside is that the interface between the app server (in our case WLS) and Toplink is proprietary and leads to maintenance nightmares. Every time WLS comes out with a service pack we run the risk that our application will break, so we are stuck in limbo until Toplink issues a corresponding patch.I'm hoping that EJB 3 will remedy this situation.

    Glad you are liking the value that TopLink adds to CMP. Our CMP for WLS product makes use of an interface between the Container and the CMP Bean Manager. While this works really well, that interface is not standardized and WLS can change it whenever they want. This is just a reality of writing on top of 3rd party software. Of course this annoyance doesn't exist when we are integrated with the OC4J Container, so I would recommend using OC4J to be rid of this problem forever :-)

    The EJB3 specification does not currently have any pluggable interfaces for EntityManagers, but that is certainly in the realm of possiblities.

    -Mike
  5. TopLink 10 Years of Persistence[ Go to top ]

    Mike Keith: In fact, I have been able to work with some of them again as a few have joined the EJB 3.0 expert group to help with the persistence specification that will emerge from JSR 220.

    Is it possible to disclose the names of JSR 243 people who have joined the JSR 220 EG? Also, when will we see the FAQ on the unified POJO persistence spec? The announcement of the joint effort is a good start, but where is the beef?
  6. TopLink 10 Years of Persistence[ Go to top ]

    Is it possible to disclose the names of JSR 243 people who have joined the JSR 220 EG? Also, when will we see the FAQ on the unified POJO persistence spec? The announcement of the joint effort is a good start, but where is the beef?

    It is no secret, and the names are going to be on the next EJB draft as well. As already mentioned there are six, except that the rep for Xcalia is Matthew Adams, not Eric Samson.

    I don't think that all press releases come with FAQ's but if you have any questions then feel free to either post them, or send them to the ejb3-feedback at sun dot com alias. If we know the answers then we will surely give them to you.

    Beef in moderation. Surely you never expected a persistence spec to spontaneously appear just because new people were added to the group? In fact, because new people have been added to the group there are actually new ideas that sometimes make it a little more time-consuming to reach consensus. That's all good.

    PSS Robin, I can't count you as one of my moderate JDO friends if you keep turning every thread into a JDO soapbox. TopLink has had 10 years of O/R success and is only getting bigger. Join the party and give us a pat on the back, at least for that. :-)

    -Mike
  7. TopLink 10 Years of Persistence[ Go to top ]

    I don't think that all press releases come with FAQ's but if you have any questions then feel free to either post them, or send them to the ejb3-feedback at sun dot com alias. If we know the answers then we will surely give them to you.

    Thanks Mike for replying to my post. Regarding the FAQ, there was great fanfare with the EJB 3.0 unified Java persistence spec press release, but it is very much short in technical details. There were so many questions left unanswered. As a result your Oracle colleague Debu Panda created his own unofficial FAQ, and I had some candid exchanges with another of your colleague Donald Smith, but all my questions remain unanswered as of today. I think the whole community was under the impression that a FAQ was imminent after the press release. If that's not the case, I am sure a lot of folks will be extremely disappointed.
  8. Hi Eric

    The following 6 members of the JDO 2.0 (JSR-243) Expert Group were invited to join the EJB 3.0 (JSR-220) Expert Group:

    Patrick Linskey
    Eric Samson
    David Tinker (replacing Keiron McCammon)
    Oliver Kamps
    Wes Biggs
    Geoff Hendrey

    Kind regards, Robin.
  9. I see all the major JDO vendors (Solarmetric, Versant/JDO Genie, and XCalia/Libelis) have their reps in the JSR-220 EG now, which is a very good thing. But don't we also need someone from the open source JDO community as well, even though they are not in the original JSR-243 EG? Similar to the situation that JBoss sits in the EG?
  10. ...don't we also need someone from the open source JDO community as well...

    A closer look at the individuals named above will show that both the XORM and the JDO Max projects are represented. (And of course it isn't just JBoss from the J2EE side either; there's a little organisation called ASF that has a seat too)
  11. Thank you Scott for the clarification. I was unable to deduce the organizational associations of some of the gentlemen in the list.
  12. TopLink: 10 Years of Persistence[ Go to top ]

    After reading all this I am still no wiser about the state of things.
    It certainly is much better for J2EE to have clarity and a single specification for persistence

    The point is not for J2EE to have a single specification for persistence - its for J2EE+J2SE to have a single specification.
    Java needs one specification covering POJO O/R mapping, not zero, and not two.

    How is that going to happen? JDO is here, widely used, and expanding, with most vendors already supporting most if not all of JDO 2.0. Hibernate is here and very widely used. TopLink is here, as are other solutions. If or when some new POJO mapping comes out , are these developers all going to migrate? If so, there would have to be a very compelling reason, and a painless migration path. Sun does not have a good history of supplying such paths, or being able to dominate in terms of standards. For example, Sun said there is one specification for GUI: Swing. However, the promised migration from IFC (which I used) never appeared, and SWT is widely used as well.

    At the moment, I see nothing but confusion around this new POJO spec. Is it just me?
  13. TopLink: 10 Years of Persistence[ Go to top ]

    After reading all this I am still no wiser about the state of things.
    It certainly is much better for J2EE to have clarity and a single specification for persistence
    The point is not for J2EE to have a single specification for persistence - its for J2EE+J2SE to have a single specification.
    Of course, Mike was talking about J2SE.
    If or when some new POJO mapping comes out , are these developers all going to migrate? If so, there would have to be a very compelling reason, and a painless migration path.
    EJB3 O/R does embrace the widely vision that came up with Hibernate, Toplink and JDO over the past 2 years. The migration path will be *really* natural for these users.
    I can speak for Hibernate and I don't see any hard migration of the Hibernate2 users, since Hibernate3 migration will be mostly a search/replace process. Hibernate3 will embrace the EJB3 spec. And... well that's all, just use the new API ;-)
    I'm pretty sure this will be the same scheme for Toplink and JDO users.
  14. TopLink: 10 Years of Persistence[ Go to top ]

    Of course, Mike was talking about J2SE.

    He mentioned J2EE and EJB3, but not J2SE.
    The migration path will be *really* natural for these users.I can speak for Hibernate and I don't see any hard migration of the Hibernate2 users, since Hibernate3 migration will be mostly a search/replace process. Hibernate3 will embrace the EJB3 spec. And... well that's all, just use the new API ;-)I'm pretty sure this will be the same scheme for Toplink and JDO users.

    I'm sorry if I seem pessimistic, but based on long and bitter experience, I see no evidence or justification for this. I see comments saying JDO users should migrate to the new API ... eventually. I see other comments saying JDO will continue. I see yet more comments that the new API will be the single standard ... in a few years, perhaps. In short, it's a confused mess! As a developer trying to plan use of technologies and APIs over a period of several years, I am after a clear statement of direction and intent regarding POJO persistence from Sun. So far, I have seen nothing that discourages me from sticking with JDO 2.0 for the forseeable future.

    There is a potential clear way forward: Sun could say that any future POJO persistence API would implement the JDO 2.0 API. This does not remove potential support for Hibernate, for EJB, for TopLink, or for other ORM systems. But, this single statement would be a real boost for a large section of the developer and vendor community.
  15. TopLink: 10 Years of Persistence[ Go to top ]

    There is a potential clear way forward: Sun could say that any future POJO persistence API would implement the JDO 2.0 API. This does not remove potential support for Hibernate, for EJB, for TopLink, or for other ORM systems. But, this single statement would be a real boost for a large section of the developer and vendor community.

    Do you want to see only one type of car? Only one type of hammer? Only one type of TV?
    Why do you want to see only one standard API?

    API is like anything else: it expresses certain way of thinking and approach. One person likes one kind and another prefers different solution.
  16. TopLink: 10 Years of Persistence[ Go to top ]

    There is a potential clear way forward: Sun could say that any future POJO persistence API would implement the JDO 2.0 API. This does not remove potential support for Hibernate, for EJB, for TopLink, or for other ORM systems. But, this single statement would be a real boost for a large section of the developer and vendor community.
    Do you want to see only one type of car? Only one type of hammer? Only one type of TV? Why do you want to see only one standard API?API is like anything else: it expresses certain way of thinking and approach. One person likes one kind and another prefers different solution.

    That is not what I am after. I'm not after one type of car... but I would like all types of cars to be able to drive on the same road! I would like all makes of TVs to be able to receive the same programs!

    I don't care what other APIs the new POJO persistence mechanism implements - I would of course be happy if current EJB users and Hibernate users could all join in. I just don't want to have to dump all my JDO 2.0 code.
  17. TopLink: 10 Years of Persistence[ Go to top ]

    That is not what I am after. I'm not after one type of car... but I would like all types of cars to be able to drive on the same road! I would like all makes of TVs to be able to receive the same programs!
    Think again. Would you like to drive a tank because sometimes there is no road? Or do you prefer everybody drive Hammers because there are unpaved roads?

    I am trying to say that common denominator does not work well in many cases therefore forcing one thing (even API) on all people and expecting them to be satisfied is a pipe dream.
  18. TopLink: 10 Years of Persistence[ Go to top ]

    I am trying to say that common denominator does not work well in many cases therefore forcing one thing (even API) on all people and expecting them to be satisfied is a pipe dream.

    Then why is Sun trying to provide a common POJO API for J2EE and J2SE?
  19. TopLink: 10 Years of Persistence[ Go to top ]

    Probably it because SUN wants to be popular too.
  20. TopLink: 10 Years of Persistence[ Go to top ]

    I am trying to say that common denominator does not work well in many cases therefore forcing one thing (even API) on all people and expecting them to be satisfied is a pipe dream.
    Then why is Sun trying to provide a common POJO API for J2EE and J2SE?

    Obviously because J2EE and J2SE persistence overlap so signficantly there is no need to have 2 different persistence APIs for J2EE and J2SE.

    Hibernate and Toplink integrate quite well with application servers and operate quite well outside application servers.

    Bill
  21. technology future[ Go to top ]

    Well, it seems with JDO 2 that the standard is well established and has growing support.

    I'd say you're correct, Steve; working with the standards and technology you already have and which work well, is an excellent way to get projects out the door.

    Eventually we might start writing code to a new API, but this will coexist; I don't expect the JDO api to ever go away. The same functionality will be available through either the JDO or JSR-220 API.

    In fact, I'm not even sure if JDO users will have much impetus to transition even over the long term -- there's an API already, why learn a different one? The 220 committee isn't going to come up with anything ground-breakingly different. (hint: it might be called EntityManager rather than PersistenceManager).

    The reason we see the 220 about-face now, is due to vendors realizing their customers are desperate for decent storage (and programming) technology. But the success stories we're hearing recently are about JDO & multiheaded Tomcat, no EJB in sight, people have been desperate for years, it might be a bit late...


    Cheers,
    Thomas
    www.powermapjdo.com
  22. TopLink: 10 Years of Persistence[ Go to top ]

    He mentioned J2EE and EJB3, but not J2SE.

    The first priority has got to be to ensure that J2EE has a persistence standard that meets enterprise developers needs. J2EE persistence is the first and most critical priority. This should not be a contentious issue as everybody that has ever done a significant amount of field work knows what applications are doing out there, and something that our 10 years has shown. By far the only two-tier persistence applications out there are left over from before the enterprise era of application Containers. Allowing the persistence spec to live outside of J2EE will come next.

    As I look back at all of the persistent threads it seems apparent that the same 5 or 6 people that either have an implementation or are self-proclaimed JDO evangelists seem to be posting on every persistence thread and saying the same thing. I would encourage you to follow the responsible lead of the only three JDO vendors that appear to have any market share. SolarMetric, Xcalia and Versant are usually quite reasonable about these things and are actively and constructively participating in the process. My suggestion would be that you do the same, and instead of simply insisting that everybody else in the world standardize on your view of persistence, try to help the process advance towards something that everybody can live with. Just my suggestion, of course. The ether is free last time I checked.

    -Mike
  23. TopLink: 10 Years of Persistence[ Go to top ]

    The first priority has got to be to ensure that J2EE has a persistence standard that meets enterprise developers needs. J2EE persistence is the first and most critical priority. This should not be a contentious issue as everybody that has ever done a significant amount of field work knows what applications are doing out there, and something that our 10 years has shown. By far the only two-tier persistence applications out there are left over from before the enterprise era of application Containers.

    There seems to be some confusion here. An API that is defined outside of the J2EE umbrella isn't automatically relegated to use in only "two-tier" applications. It just means that you don't have to rely on a J2EE application server to provide your middle-tier for you. Being employed by Oracle, I can see how your view would be naturally biased towards J2EE as "the only middle-tier". I suppose we couldn't expect anything more from you.

    If I am forced to choose between APIs that can work in any environment (for example, JDO), or an API primarily designed for use in a J2EE application with EJB, the decision is simple.

    God bless,
    -Toby Reyelts
  24. TopLink: 10 Years of Persistence[ Go to top ]

    If I am forced to choose between APIs that can work in any environment...or an API primarily designed for use in a J2EE application with EJB, the decision is simple.

    Perhaps you've missed some developments over the past couple of months. Many key contributors from JDO are now on the EJB 3.0 expert group and will certainly be advocating for the J2SE users. Moreover, as noted and demonstrated extensively, EJB3.0 persistence is based heavily on the success of POJO persistence layers like TopLink and Hibernate.

     - Don
  25. Missed developments[ Go to top ]

    Perhaps you've missed some developments over the past couple of months. Many key contributors from JDO are now on the EJB 3.0 expert group and will certainly be advocating for the J2SE users.

    No, I've been following the developments very closely. I think you said it all. "Many key contributors from JDO are now on the EJB 3.0 expert group"

    There is tons of uncertainty when it comes to a unified persistence API. At this very moment in time, I can use JDO inside or outside of an EJB container w/o problems. Making plans to tie myself to a persistence API designed by an EJB expert seems very unwise.

    God bless,
    -Toby Reyelts
  26. TopLink: 10 Years of Persistence[ Go to top ]

    .. self-proclaimed JDO evangelists seem to be posting on every persistence thread and saying the same thing.

    There is a good reason for this. These people keep asking the same questions, but keep getting no sensible or coherent answers.
    My suggestion would be that you do the same, and instead of simply insisting that everybody else in the world standardize on your view of persistence, try to help the process advance towards something that everybody can live with. Just my suggestion, of course. The ether is free last time I checked.-Mike

    As far as I am concerned, all I am after is some simple and straightforward answers about why things are being done. There is soon to be a standard for POJO persistence that is rich and full-featured - its called JDO 2.0.

    After all this work, with all the time and effort that went into it, why not take this excellent standard and extend that? Why a new, incompatible API? There is no reason why Hibernate 3.0 could not have a JDO 2.0 interface added, for example. I don't feel that JDO and the way it works is perfect or complete, but surely its a reasonable place to start, rather than something that should be deprecated or sidelined.

    I have this troubling suspicion that the reason for the new API is political, not technical - a way of appeasing various groups who felt they could not support JDO for whatever reasons.

    It would be interesting and helpful if you have any comments about why current standards such as JDO 2.0 are so troublesome to live with: I think it would help explain the situation.
  27. TopLink: 10 Years of Persistence[ Go to top ]

    There is a good reason for this. These people keep asking the same questions, but keep getting no sensible or coherent answers.

    You might want to consider the possiblity that you are getting the answers but you just don't want to hear them.
    As far as I am concerned, all I am after is some simple and straightforward answers about why things are being done. There is soon to be a standard for POJO persistence that is rich and full-featured - its called JDO 2.0.After all this work, with all the time and effort that went into it, why not take this excellent standard and extend that? Why a new, incompatible API? There is no reason why Hibernate 3.0 could not have a JDO 2.0 interface added, for example. I don't feel that JDO and the way it works is perfect or complete, but surely its a reasonable place to start, rather than something that should be deprecated or sidelined.

    Okay, here is your answer... again. Please don't repeat on this thread or any other that you have not received an answer. It is fine for you to disagree, but please don't say that you never got an answer.

    This has been discussed over and over again, and I have no plans on getting pulled into a "This is better ... No, this is" argument, which is what would happen if I gave you a technical checklist of the issues. The disagreements have already been vetted and are in the annals of TSS history. The fact is, as hard as it is for you to hear this, and no disrespect intended, not everybody agrees with you that JDO is an excellent standard. You may, and some others may, but lots don't. If people are not convinced of the excellentness of a standard then they don't simply adopt that standard. It's that simple. You can tell people how great you think something is as much as you want, but telling people that they are messed up because they don't like it...well, that likely won't get them to change their mind.

    Now back to the regularly scheduled party...
  28. JSR-220[ Go to top ]

    This has been discussed over and over again, and I have no plans on getting pulled into a "This is better ... No, this is" argument, which is what would happen if I gave you a technical checklist of the issues. The disagreements have already been vetted and are in the annals of TSS history. The fact is, as hard as it is for you to hear this, and no disrespect intended, not everybody agrees with you that JDO is an excellent standard. You may, and some others may, but lots don't. If people are not convinced of the excellentness of a standard then they don't simply adopt that standard. It's that simple. You can tell people how great you think something is as much as you want, but telling people that they are messed up because they don't like it...well, that likely won't get them to change their mind.

    I am breaking my self-imposed no-TSS-posting-ban to echo Mike on this. (Don't expect any more posts from me, I don't like posting in paces where every discussion degenerates into personal attacks.)

    The truth of the situation is that there are a number of us here who are honestly, genuinely trying to create the best persistence spec that the Java community can possibly have. Believe it or not, we have incredibly pure motives: we want to ceate great technology; we are not primarily motivated by politics or whatever. *Nobody* has more experience of ORM than the TopLink team: they have been doing this for ten years. In addition, Hibernate and TopLink have the biggest userbases of any "transparent" persistence solutions *ever*. Between the two of us we have overwhelming marketshare in Java ORM. The Hibernate and TopLink teams, along with the established J2EE vendors, have made the determination that JDO 2.0 is not the best solution that the Java community could possibly have. You are very welcome to disagree, but it is not as if we have not put a *lot* of thought into this, over the space of several *years*. I could try to justify our decision with technical reasons, but last time I posted on that topic, I had my name dragged through the mud, and was subject to all kinds of dishonest smears, and misleading technical claims. So I have learned my lesson and will not do this again.

    The EJB 3.0 specification is (or at least, will be), IMO, a distillation of the best ideas in ORM persistence that

    (1) does everything users need
    (2) is very easy to use
    (3) is no more complex than it needs to be
    (4) allows competitive implementations by many existing vendors with differing approaches
    (5) integrates elegantly with the J2EE stack and programming model
    (6) may be used outside the context of J2EE

    Now, to gain the benefits of the new spec, yes, some people will need to port some parts of their application from whatever object persistence solution they are currently using. The groups of people we are thinking of include (in order of numerical size):

    (1) Current CMP users
    (2) Current Hibernate users
    (3) Current TopLink users
    (4) Current JDO users

    So, each of our user communities will suffer some pain when they adopt EJB 3.0 persistence. The BIGGEST pain will be felt by CMP users, who are actually the largest group of users (though apparently not the noisiest).

    It is the job of vendors to provide clear and reasonable migration strategies for existing users, and to commit to continuing support for existing APIs for those users who do not want to migrate. Speaking for Hibernate/JBoss, this means:

    (1) we promise to continue supporting and improving the existing Hibernate API, which goes beyond what is available in persistence standards at this time (we see a class of users who will prefer to use Hibernate APIs to EJB 3.0 APIs)
    (2) we will provide a clear migration strategy where Hibernate code and EJB 3.0 code coexists in a single application, and metadata, object model, and APIs may be migrated independantly (!)
    (3) we will provide vendor-specific functionality that extends the EJB 3.0 specification for those users who need cutting edge features (eg, Hibernate3 filters for temporal data), and are not overly concerned about portability
    (4) we will continue our work in the JSR-220 committee, to ensure that the spec evolves to continue to meet the needs of users
    (5) we will continue our work in Hibernate to innovate new ideas in ORM

    Your vendor should be able to give you a similar set of guarantees; if they are unable to, you should consider finding a new vendor. What I'm saying is that this is an issue between you and your vendor. It is not Mike's job, nor my job, to ensure that Solarmetric customers experience smooth migration to EJB 3.0. Nor is it our job to defend and promote a specification if we do not believe it is the best solution.

    Regards,
    Gavin
  29. JSR-220[ Go to top ]

    *Nobody* has more experience of ORM than the TopLink team: they have been doing this for ten years. In addition, Hibernate and TopLink have the biggest userbases of any "transparent" persistence solutions *ever*. Between the two of us we have overwhelming marketshare in Java ORM. The Hibernate and TopLink teams, along with the established J2EE vendors, have made the determination that JDO 2.0 is not the best solution that the Java community could possibly have. You are very welcome to disagree, but it is not as if we have not put a *lot* of thought into this, over the space of several *years*.

    Gavin:

    IMHO, your technical insight is greatly appreciated by the majority here, if not everyone. Now allow me to ask a question, and if you don't think you are the right person to answer it because of concern out of conflict of interest, just make a disclaimer:

    A few years back Cocobase was as popular as TopLink, competing head-to-head. However, they have now fallen off the ORM map - because of a), the fast-rising popularity of Hibernate, b), a more powerful vendor Oracle is now behind TopLink, and c) the personalities at the Thought Inc. did not help matters at all. But to be objective, have you guys examined Cocobase techincally and see whether there is something worth borrowing - or you guys don't even want to touch that beast with a 8 ft pole because of their hardline stance on their "IP"? Just curious.
  30. JSR-220[ Go to top ]

    It might be a surprise to many but we never looked much at other ORM solutions in the early days of Hibernate. As Gavin said in a recent interview, we have been doing some competitive analysis recently but haven't found much not already implemented in Hibernate3 or on TODO.

    My personal experience with Toplink was also very short; I've started the mapping workbench, it crashed after three clicks, I deleted it. (This was > 3 years ago though, after they joined Oracle.) I've never even tried Cocobase; after looking at some documentation examples it was clear to me that it had an extremely weird API and I wouldn't like working with it. This was the time when I decided to help with Hibernate. ;)

    We really prefer working from the basics and good data management practices instead of copying other tools and we have good success with this strategy. What is a surprise is how close our result is to Toplink from a conceptual point of view, a further indicator that the approach of Toplink and Hibernate is what works best for transparent persistence.
  31. JSR-220[ Go to top ]

    Gavin,

    Thanks for breaking your silence and providing a very sensible view of customer migration to EJB3. Although I do not speak for *any* vendor in the process, my impression is that all of them supporting JSR 220, including the recently joined JDO vendors, are taking a similarly sensible approach to migrating their users to the future API.

    The only part I want to add to is this:
    The groups of people we are thinking of include (in order of numerical size):
    (1) Current CMP users
    (2) Current Hibernate users
    (3) Current TopLink users
    (4) Current JDO users

    There is another important group I always keep in mind:

      (0) Current JDBC users

    Given how much attention object persistence has had in recent years it continues to surprise me (and sadden me a little) that the crank-your-own JDBC approach is still widespread. To me, it is evidence that none of the existing object persistence solutions has yet been compelling enough. My hope is that the new POJO persistence standard will be the first to get the features, the ease-of-use, the portabiliy etc to convince everyone that it's worth working at a higher level of abstraction than JDBC.
  32. JSR-220[ Go to top ]

    (0) Current JDBC usersGiven how much attention object persistence has had in recent years it continues to surprise me (and sadden me a little) that the crank-your-own JDBC approach is still widespread.
    It is hard to sell persistence for JDBC users, they do not have problem with persistence.
  33. JSR-220[ Go to top ]

    It is hard to sell persistence for JDBC users, they do not have problem with persistence.

    Apart from the issue of portability, it has been my experience that any sufficiently large JDBC-based project ends up as a do-it-yourself ORM: The alternative being huge amounts of replicated code for managing the interface between objects and databases. If this is the case, doesn't it makes sense both in terms of time and cost of developer-hours to bring in a ready-made solution: something like TopLink (or Hibernate, or JDO)?
  34. TopLink: 10 Years of Persistence[ Go to top ]

    Mike:

    I think this presents an excellent case for having an FAQ on the unified Java persistence spec, so that the official answers are out there and clear to everyone. You are right that not everyone sees things the same way and I don't think it will ever be, but at least the community sees what the thinking of the JSR-220 EG is. They can choose to agree or disagree, from that point on it is a natural selection and evolution process. Without such a FAQ, there will always be a lot of guesses around and it is a lot harder to forge a common ground within the community. Rational debates can only come out of open channels/processes with lots of information and full disclosures (not accusing you guys of hiding anything, just a generic comment).

    BTW, if you have time, I would like to hear official answers to my questions, for which Mrssrs. Donald Smith and Debu Panda kindly replied but I would like to verify their answers represent the EG's opinion as well.

    1. Is it a natural situation to have a container-independet spec live in a container-dependent JSR?
    2. If the answer to 1 is no, will this problem ever be corrected? If yes, when?
    3. Do the 2 specs under JSR-220 have independent release cycles? If yes, how will that be mananged?
    4. Up to date J2SE and J2EE have had independent release cycles. Do you see any chance that that need to be tied together from now on because EJB 3. 0 belongs to J2EE 5.0, and part of the JSR has nothing to do with J2EE?
    5. Will the entire EJB 3.0 EG handle ALL issues related to the JSR, i.e., both specs? Do you see any chance of losing focus or splitting the resource? Are we going to have 2 separate sub-EG's?
    6. To be standard compliant, is it required that the JDO implementations support both specs in the JSR-220?
    7. Is there a separate name for the unified persistence spec? Calling it EJB 3.0 doesn't sound right if you ask me.

    Thanks again,
  35. TopLink: 10 Years of Persistence[ Go to top ]

    1. Is it a natural situation to have a container-independet spec live in a container-dependent JSR?

    The persistence specification is not a container independent specification and it is not a container-dependent specification. It is a persistence specification period. A spec that addresses integration in a J2EE environment and integration within a J2SE environment. Let's face it. The majority of persistence is not how it integrates in a app server or outside an app server, but rather, how it does O/R mapping and how you do queries.

    For J2EE 1.5, JBoss Inc. will push for the EJB and persistence specification to have concurrent release cycles.

    We also strongly believe that the new persistence spec should be called EJB 3.0 period. Let's face it...JDO was a failure at marketing itself. People are familiar with EJB and EJB is more widely adopted than JDO, Hibernate and Toplink combined. Changing the name of the persistence specification would be a mistake. Does Microsoft change the name of Microsoft Office every release? They don't, because they understand how to market their products. Why invest in a new brandname for persistence when EJB is already entrenched and established?
    Up to date J2SE and J2EE have had independent release cycles. Do you see any chance that that need to be tied together from now on because EJB 3. 0 belongs to J2EE 5.0, and part of the JSR has nothing to do with J2EE?

    It is my understanding as an EG member that persistence is not being added to J2SE, but rather, EJB persistence is being made available outside of the container. Just as JMS and other J2EE specifications don't have to run in a J2EE application server.
    5. Will the entire EJB 3.0 EG handle ALL issues related to the JSR, i.e., both specs? Do you see any chance of losing focus or splitting the resource? Are we going to have 2 separate sub-EG's?

    The way it is working now, there is not sub-EGs inside JSR-220 and there is not a need to have sub-EGs inside JSR-220.

    Bill
  36. TopLink: 10 Years of Persistence[ Go to top ]

    Bill:

    You bring in a very interesting perspective, even though it is probably an EJB-container vendor leaning (to put it mildly :-) perspective. Nevertheless, I still appreciate your candidness and thank you for taking time to read and reply to my questions.

    I could imagine that any answers that come from Mike Keith, or Donald Smith, or Debu Panda, or Linda DeMichiel as an individual tend to, to certain degree, slant towards what their organizations represent - EJB container vendors. Hey, I would do the same if I were in that position.

    Perosnally however, I still want to hear from the JDO vendors who recently join the JSR-220 EG, as well as independent voices like Scott Crowford, Cedric Beust now that he is at Google and not BEA, Richard Monson-Haefel if he still cares about J2EE :-), and reps from Apache, if they actively participate in shaping the persistence spec, and non-professional open source groups who IMHO may have more pride on the line than commercial interests (nothing wrong with having commercial interest, let me add).

    The more constructive discussions we have, I think the better chance we get to succeed.
  37. TopLink: 10 Years of Persistence[ Go to top ]

    Perosnally however, I still want to hear from the JDO vendors...

    I can't speak for all JDO vendors, but SolarMetric at least is committed to fully supporting both JDO 2 and EJB 3 persistence. JDO 2 offers many features not found in EJB 3, and EJB 3 has a few features not found in JDO 2. We feel that choice can only benefit our customers. Kodo will offer complete interoperability between the two APIs; you'll be able to use the same objects under both systems at the same time, and to switch back and forth freely.

    The JDO 2 final draft specification will be released relatively soon, and we feel that JDO is the best solution for current projects. When EJB 3 stabilizes, we expect some developers to begin using it as well. They can start by using it in small portions of their application, side by side with their existing Kodo JDO code. This makes migration a non-issue. We also expect many of our customers to prefer JDO, and to continue to use it indefinitely.
  38. TopLink: 10 Years of Persistence[ Go to top ]

    Well said Abe.

    This is exactly how we see it with Versant Open Access. We will support EJB3 and JDO side by side in the same application. We already have a .NET JDO-like API using the same O/R mapping engine so this is not new :)

    I think all of the main JDO vendors are going to follow this strategy.

    Cheers
    David
    Versant Open Access
  39. TopLink: 10 Years of Persistence[ Go to top ]

    OK. So you guys are bending backwards to accommodate both the JDO and EJB specs. If I understand correctly your products will always be fully JDO spec compliant but only partially EJB spec compliant because of the EJB 1.x and 2.x stuff will not be supported.

    Down the road, are you guys confident that you can meet the independent release schedules followed by the 2 specs? What if both JDO and EJB come out with new versions at the same time (for argument sake :-)?
  40. TopLink: 10 Years of Persistence[ Go to top ]

    Down the road, are you guys confident that you can meet the independent release schedules followed by the 2 specs? What if both JDO and EJB come out with new versions at the same time (for argument sake :-)?

    I'm not concerned. Specifications don't spring up over night; many months of work go into each revision, giving vendors plenty of lead time to implement new requirements. Also, most of the work in a persistence product goes into the "kernel". While implementing a specification is a significant undertaking, in a sense it's just making sure your existing features are exposed through the right interfaces. SolarMetric certainly doesn't foresee any EJB 3 features that will be difficult to implement on top of Kodo's kernel, and we expect the same to hold true for future EJB versions. JDO has some interesting functionality that pushes the envelope a little more, but we've had no problem staying well ahead of the curve thus far, and we will continue to do so.
  41. TopLink: 10 Years of Persistence[ Go to top ]

    Will you ever foresee a situation where for the same functionality the JDO spec wants it one way and the EJB spec another? Are the 6 JDO members in the JSR-220 EG influencial enough to reach compromises with the EJB vendor members? Or will JDO do a wholesale import of the EJB 3.0 unified Java persistence spec for its OR mapping sub-spec in order to avoid conflicts, and then layer on top of it the common JDO API?
  42. TopLink: 10 Years of Persistence[ Go to top ]

    Will you ever foresee a situation where for the same functionality the JDO spec wants it one way and the EJB spec another?

    There are certainly small semantic and syntactic differences between the two specs, but those differences can all be handled at the "API layer" of the implementation. I can't imagine any conflict so fundamental that implementing EJB persistence and JDO persistence will require two completely different kernels.
    Are the 6 JDO members in the JSR-220 EG influencial enough to reach compromises with the EJB vendor members?

    I believe that each spec team is trying to create the best solution for its target audience. Where the two specs are already very similar, we might be able to align them. But I don't believe either team is going to do anything that it feels will dilute its spec just for the sake of alignment with the other. I want to stress that this is only my impression; I cannot speak for either expert group as a whole.
    Or will JDO do a wholesale import of the EJB 3.0 unified Java persistence spec for its OR mapping sub-spec in order to avoid conflicts, and then layer on top of it the common JDO API?

    The future direction of JDO is up to the community. JDO 2's ORM capabilities seem to go beyond what the initial EJB 3 release will offer, so adopting EJB 3's ORM won't be feasible at first (at least not without extension). But who knows what the future holds.
  43. TopLink: 10 Years of Persistence[ Go to top ]

    Orient Technologies will continue to support JDO 2 and the next thing: EJB 3 or whatever will born.

    Orient Technologies is releasing Orient ODBMS product and its JDO implementation as open source and free for use, also for commercial purpose.

    Very soon Java developers will have a complete JDO solution for free and contribute to the develop itself

    bye,
    Luca Garulli
    OrienTechnologies.com - Light ODBMS, All in one JDO solution
    www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
  44. the 'EJB' brand[ Go to top ]

    Why invest in a new brandname for persistence when EJB is already entrenched and established?

    - because when you suggest using EJB for persistence, customers run away screaming. Let's face it - the EJB brand has a very bad reputation when it comes to persistence. Otherwise people wouldn't be flocking to JDO, Hibernate, Spring, etc, and the EJB expert group wouldn't have dumped its heavyweight model in favour of lightweight POJO-based persistence.

    - and again, I think it will only confuse the majority of Java developers when you say you can use EJB for persistence even when you don't use an EJB container. So, to accomodate all the JDO-haters out there, why don't we come up with a new for the persistence API that doesn't have the EJB brand baggage.

    Dave.
  45. TopLink: 10 Years of Persistence[ Go to top ]

    Eric,

    I am happy to answer your questions as best as they can be answered at this point in time. To be fair lots of things have happened and stuff is still happening, but it is all good stuff.
    1. Is it a natural situation to have a container-independet spec live in a container-dependent JSR?

    I actually already answered this one. The highest priority is to standardize enterprise (J2EE)
    persistence and to ensure that it is properly integrated into the J2EE stack. Once this is done a minimal
    set of API's can be added to enable use in non-J2EE environments.
    2. If the answer to 1 is no, will this problem ever be corrected? If yes, when?

    There is no problem to correct.
    3. Do the 2 specs under JSR-220 have independent release cycles? If yes, how will that be mananged?

    No. Both specification documents are part of EJB 3.0 and will therefore have their final release with J2EE 5.0.
    4. Up to date J2SE and J2EE have had independent release cycles. Do you see any chance that that need to be tied together from now on because EJB 3. 0 belongs to J2EE 5.0, and part of the JSR has nothing to do with J2EE?

    The JSR currently has everything to do with J2EE. Just because it will be executable outside the J2EE environment does not mean that it is not an integrated part of the specification. As to subsequent releases it is not appropriate for me to comment since this is not in the scope of This will not affect the J2SE and J2EE life cycles.
    5. Will the entire EJB 3.0 EG handle ALL issues related to the JSR, i.e., both specs? Do you see any chance of losing focus or splitting the resource? Are we going to have 2 separate sub-EG's?

    No, in fact all of the new members from the JDO expert group have been welcomed as full participants in the EJB 3.0 group and some of them have been making productive contributions to aspects of the specification beyond persistence.
    6. To be standard compliant, is it required that the JDO implementations support both specs in the JSR-220?

    To be clear a JDO implementation is only required to implement JDO. If a JDO vendor wants to be compliant with the new persistence standard then by all means they should implement it. I believe that the licensing will accomodate implementing an EntityManager, since at least one JDO vendor that I know of is planning on doing exactly that.
    7. Is there a separate name for the unified persistence spec? Calling it EJB 3.0 doesn't sound right if you ask me.

    I can assume that naming is being worked out, but to be honest I am hoping that people care more about the technology than what it's called.

    -Mike
  46. TopLink: 10 Years of Persistence[ Go to top ]

    Hi Mike

    My concern as a consumer is this:

    When I need a _standard_ commercial persistence solution I pay only for that by going for JDO. By going for EJB 3 based persistence I end up paying for every thing “Enterprise”, not only persistence. Can a vender only implement part of the EJB 3 which deals with the new persistence mechanisms and will it be certified as standard? If yes this will be ideal for me as I can buy just the persistence part only. (And it will be standard)

    Thanks

    Pratheep
  47. TopLink: 10 Years of Persistence[ Go to top ]

    This question has been answered several times in this thread.
  48. TopLink: 10 Years of Persistence[ Go to top ]

    I don’t think so.

    Just give me a Yes/No Anwser.

    If I go for standard commercial EJB 3 persistence I’m forced by buy things not related to persistence (Y/N)?

    Pratheep
  49. TopLink: 10 Years of Persistence[ Go to top ]

    Asked and answered several times. There will be be vendors supporting EJB3 persistence only. You can bet on it. You won't be "forced to buy things not related to persistence".

     - Don
  50. TopLink: 10 Years of Persistence[ Go to top ]

    Yes. I know that

    Will it be certifed as standard? (yes/no)

    Pratheep
  51. TopLink: 10 Years of Persistence[ Go to top ]

    I think people generally confuse the words "standard" and "specification" (i.e., it's easy to be one and not the other and vice versa), hard to be both. The good news is that finally the answer to your question will be yes, regardless of what you really mean. :)

     - Don
  52. TopLink: 10 Years of Persistence[ Go to top ]

    Well these are my needs:

    I like to use a certified product. (Certified as compliant to a JSR specification)
    I have to use a commercial product. (Customer policy)
    I need a persistence solution (only).
    I don’t need an application server.

    Currently JDO fits these needs. Technically EJB 3 persistence may to be superior to JDO. But my concerns are not technical. If the persistence part of the EJB 3 comes under a separate JSR then I get everything.

    Anyway thank you for the answer.

    Pratheep
  53. Hibernate and Toplink Features[ Go to top ]

    I'm a Toplink developer, and have started learning Hibernate. I would be interested to hear from people who have worked with both on problems or benefits you found.

    One feature that I already miss is the ability to auto generate my xml descriptors based on an existing tables. It was a nice way to get jump started.
  54. Hibernate and Toplink Features[ Go to top ]

    One feature that I already miss is the ability to auto generate my xml descriptors based on an existing tables. It was a nice way to get jump started.
    Hibernate provide such feature using Middlegen (bottom-up approach)
    http://hibernate.org/About/DevelopmentProcess
  55. 1. transparent persistence.
    I had used both hibernate and toplink. Hibernate supported transparent persistence. It works like the JDO. You just modify the object. Then commit the transaction. It makes the code very clean. Source code is only polluted in a few location by the persistence logic.
    On the other end, toplink uses the notion of UnitOfWork. Everywhere, you'd like to modify the object. The source code is polluted with the toplink UnitOfWork concept. Moreover some business logic can not be supported by the UnitOfWork program model.
    2. TopLink gives surprise all the time. I have experienced some surprise during my development, especially some deadlock issuse in the database although I read the topLink documentation carefully for several times. My final conclusion is that " buy Oracle support first if you plan to use topLink".
    Definitely hibernate also has some drawback such as performance issue. However it is better than toplink at it current stage.
  56. transparent persistence is the key[ Go to top ]

    Hi Jiesheng, welcome to the server side and congrats on your first post!

    A rose by any name smells as sweet. TopLink uses the term "unit of work", the same term that Martin Fowler would later use in his "Patterns of Enterprise Architectures" book. Other persistence layers choose to manage this pattern of behavior at the session level. Personally, I find managing UOW's at the session level misleading and in the long term confusing. Regardless of if your persistence layer uses a "unit of work" pattern in the "session" or in a, uh, "unit of work", in a non-trivial application there is no more or less transparency with either approach. The discussion forums of all persistence layers will have discussions on deadlock avoidance stategies.

     - Don
  57. transparent persistence is the key[ Go to top ]

    Jiesheng,

    Wherever you got your notion of transparent persistence, I can tell that it wasn't from any persistence vendor, or somebody that understood persistence :-). Tranparency does not imply that there is no visible persistence API. What it means is that the domain model does not have to call out to that API. So in other words the persistent objects do not have to be aware of the mechanism whereby they are persisted.

    TopLink, Hibernate, JDO and a few others offer non-intrusive persistence frameworks where the object model does not need to be changed in order to persist the objects. They do this despite the fact that users at some point all need to call into the TopLink UnitOfWork/Session, Hibernate Session or JDO PersistenceManager. It would actually be really bad if this were not the case and persistence was magic, because that would take the necessary control away from the application.

    So, I forgive you for your misstatement (this time only ;-), but would encourage you to learn a little more about persistence and TopLink in particular. You will find that it works exactly the same as what you did with Hibernate (except that you will have a few more features available to you ;-) i.e. you modify the object, then commit the transaction. I agree that support is recommended for beginners, though, because no matter what product you use if you don't understand the technology then you could get yourself into difficult situations, deadlock being one of them.

    -Mike
  58. Choices are good[ Go to top ]

    POJO persistence is such a fundamentally important technology that it's no surpirse that we now have many choices. It's great that EJB 3.0 asked me and others from the JDO 2.0 group to provide input on the O/R mapping format, etc.

    What this cooperation does not mean is that our choices will be restricted in the future. Certainly I don't expect it to limit development of the JDO spec, as there is a great grassroots and OS community around JDO.

    -geoff
  59. Choices are good[ Go to top ]

    POJO persistence is such a fundamentally important technology that it's no surpirse that we now have many choices. It's great that EJB 3.0 asked me and others from the JDO 2.0 group to provide input on the O/R mapping format, etc.What this cooperation does not mean is that our choices will be restricted in the future. Certainly I don't expect it to limit development of the JDO spec, as there is a great grassroots and OS community around JDO. -geoff

    I think this is a useful attitude, but I'm afraid I have a point of view that I think may be shared by many JDO users: JDO 2.0 is a very rich ORM specification, with features that have been requested from the Java community over years: a powerful query language, flexibility, cache management, a range of useful object states, the ability to detach and attach objects, aggregates etc. And, its a standard. I can't see the point in re-inventing all this with a new peristence API. There may be some extra features, currently provided in proprietary ways by most JDO vendors, that need to be standardised - the O/R mapping, clustering, the ability to use different query languages. There already is a JCP standard for POJO persistence - JDO! Why is there a need for a new one?
  60. TopLink: 10 Years of Persistence[ Go to top ]

    There's a lot more information on the 10th Anniversary party here.

    Some exciting stuff coming up at Oracle World in 3 weeks also, some stuff that's out of this world in fact!

     - Don
  61. TopLink: 10 Years of Persistence[ Go to top ]

    Don:

    Really enjoyed reading your article over at the OTN site on the history of TopLink. Quick question, don't you think it is time for someone to write a book on TopLink? If Hibernate can have at least 3 books published in its short 2.5 years of existence, you guys can do the same or better.
  62. TopLink: 10 Years of Persistence[ Go to top ]

    Are you volunteering? :)

    All I can say is stay tuned...

     - Don