Skip to content

Do you have an impedance mismatch problem? Users speak up! Second series of user reports published.

by Roberto V. Zicari on September 4, 2008

I have started a new series of interviews with users of technologies for storing and handling persistent objects, around the globe.

6 additional user reports (12-17/08) have been published, from the following users:

  • Ajay Deshpande, Persistent
  • Horst Braeuner, City of Schwaebisch Hall
  • Tore Risch, Uppsala University
  • Michael Blaha, OMT Associates
  • Stefan Keller, HSR Rapperswil
  • Mohammed Zaki, Rensselaer

The complete initial series of user reports is available as always for free download.

Here I define “users” in a very broad sense, including: CTOs, Technical Directors, Software Architects, Consultants, Developers, Researchers.

I have asked 5 questions:

Q1. Please explain briefly what are your application domains and your role in the enterprise.

Q2. When the data models used to persistently store data (whether file systems or database management systems) and the data models used to write programs against the data (C++, Smalltalk, Visual Basic, Java, C#) are different, this is referred to as the “impedance mismatch” problem. Do you have an “impedance mismatch” problem?

Q3. What solution(s) do you use for storing and managing persistence objects? What experience do you have in using the various options available for persistence for new projects? What are the lessons learned in using such solution(s)?

Q4. Do you believe that Object Database systems are a suitable solution to the “object persistence” problem? If yes why? If not, why?

Q5. What would you wish as new research/development in the area of Object Persistence in the next 12-24 months?

More information here.

From → Uncategorized

2 Comments Leave one →
  1. Having read through these user reports, which I find genuinely informative, I am surprised that nobody has pointed out a major shortcoming of Object-Relational Mapping (ORM) products such as Hibernate and its descendant, JPA: because they are designed to be portable across many different relational DBMSs, they cannot handle proprietary extensions to standard SQL, and in particular, cannot exploit the power of stored procedures, which are not compatible across different RDBMS. In many environments, stored procedures are mandated as a way for Web applications to access data – for various reasons, including security (no possibility of SQL injection attacks). Zühlke and its customers have had very good experiences with the Spring JDBC support ( for both stored procedure access and ORM.

  2. Hi Immo
    in fact, we had a detailed discussion on this issue in two articles I published:

    Java Object Persistence: State of the Union PART II
    with Jose Blakeley (Microsoft), Rick Cattell (Sun Microsystems), William Cook (University of Texas at Austin), Robert Greene (Versant), and Alan Santos (Progress).


    Java Object Persistence: State of the Union I
    with Mike Keith: EJB co-spec lead, main architect of Oracle Toplink ORM, Ted Neward: Independent consultant, often blogging on ORM and persistence topics, Carl Rosenberger: lead architect of db4objects, open source embeddable object database, and Craig Russell: Spec lead of Java Data Objects (JDO) JSR, architect of entity bean engine in Sun’s appservers prior to Glassfish

    I`d be interested to learn your opinion on that…

    Best Regards

Leave a Reply

Note: HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS