Discussions

News: The JPA 2.0 EntityManager vs. the Hibernate Session: Which one to use?

  1. It's the age-old question that almost all enterprise data architects have to ask themselves at some point in time: When using the Hibernate ORM framework with the Java Persistence API (JPA), should data access be mitigated through the JPA 2.0 EntityManager or through the underlying Hibernate Session?

    EntityManager is part of the Java Persistence API (JPA) standard, and who can really argue against using something that is standardized? But, of course, the problem with a standard is that it often represents the lowest common denominator with regards to what everyone in the community can agree upon. And who wants to use the tool that represents the lowest common denominator?

    Read the full story and interview with Emmanuel Bernard

     

  2. migration path?[ Go to top ]

    Is it possible to use the native/proprietary Hibernate XML Mapping files with JPA 2 at the API level assuming Hibernate as persistence provider?

    Is this migration path recommended, any gotchas?

    What would be really useful is a Hibernate to JPA 2 migration guide both at the API and mapping level...

     

  3. migration path?[ Go to top ]

    I think the right place for this feedback might be the Hibernate forums... Reza Rahman | Java EE/GlassFish Evangelist All views voiced are my own, not necessarily Oracle's.
  4. I don't see any reason to use JPA 2.0 EntityManager, because I can't think of switching the JPA provider when I started the project using Hibernate.

     

    By the way there are some features that JPA lacks, most important one is @Filters which are always used within our projects.

  5. I also would use Hibernate's Session explicitely. First (back then when JPA was born from Hibernate and Hibernate was the first RI) I wanted to use "pure" JPA, but after first headaches, I am using Hibernate's API, not JPA.

    Of course this is "evil" because it's not a praise of JPA and JavaEE in general, but I'm pragmatist, not evangelist.

    Once I wanted to just "switch the JPA implementation". But believe me - even if I were using EntityManager's API, the "switch" was not as easy as JavaEE specs promise. Eclipse Link has different dependencies, different Maven repos, different deployment lifecycle (generation of some intermediary code). Also recently I wanted and had to use not JPA annotations (though I like them) but Hibernate's XML mapping files and you know what? They're clean, simple and give me what I want - separation of Java code and mapping information.

    The same case is with JaxWS - you ust can't switch CXF to Axis2. CXF has it's configuration, it's concepts (bus, interceptors, handlers) which JaxWS spec don't cover.

    So don't feel guilty (as I felt few years ago) for not using "pure JPA/JaxWS". Just do what works. Using explicit Hibernate/CXF is not evil, not dirty, not proprietary, not legacy and not passe..

    regards

    Grzegorz Grzybek

  6. Pragmatism - really?[ Go to top ]

    No standard guarantees 100% portability. If it insisted upon it, it would instantly kill all innovation. What standards do is try to maximize portability, vendor/implementation-neutrality and compatibility. Most companies value this for the entirely pragmatic reason of keeping their options open without sacrificing much (certainly in the case of JPA). BTW, I've held these views as a professional long before I had anything to do with Java EE or Oracle. I've certainly not declared myself an "enthusiast" of anything as it pertains to professional matters. I'm not sure how that squares with the claim of pragmatism.Reza Rahman | Java EE/GlassFish Evangelist All views voiced are my own, not necessarily Oracle's.
  7. Pragmatism - really?[ Go to top ]

    Reza - nice to meet you again :)

    @Holger wrote an important words:

    assuming Hibernate as persistence provider

    I respect the idea of standards, their influence on innovation, unification and safety of developers' choices. But let's consider two kinds of standards:

    • protocols and formats such as: TCP/IP, XML, HTML[5], AMQP, ASN.1, EDI, SMTP, ...
    • APIs: JDBC, JMS, POSIX, M4 macro processor (to name few from different worlds)

    The former are great and their role is undiscussable - you're either compliant or you have problems. But IMO there's a little problem with the latter. You have to (just like @Holger) assume some implementation. Sometimes less strictly (as with JDBC and JMS) and sometimes you have to be more conscious (as with JPA - I had the same problems while trying to migrate from Hibernate to EclipseLink). In POSIX world you either stick to (quite large) common denominator with e.g., AWK or MAKE implementations or use e.g., GNU Extensions.

    The question is - how often do you need extensions - once you choose them you almost can't switch - that's nothing new.

    If you're happy with pure JPA - fine. If you want Hibernate XML mapping - that's nothing heretical.

    I agree that vendor neutrality is great option - I'd be very happy to be able to switch from WebSphere/DB2 to e.g., Tomcat/PostgreSQL (and that's what I did recently). But my experience shows that one of vendor neutrality's flavours is large and vibrant community which won't allow a product to become a lock-in. I think that's what happened to Spring a few years ago - do you remember these "enterprise options" and removing tags from SVN? Now all Spring products are hosted on Github and no one talks about Spring licences. (I don't say that it won't happen in the future!).

    regards

    Grzegorz Grzybek

  8. Pragmatism - really?[ Go to top ]

    <p>There is indeed nothing that unusual with not opting for vendor-neutrality. There are after all legions of Microsoft, Apple, etc developers that are perfectly happy being bound to single vendors/implementations. I've always seen the value in vendor-neutrality and why I chose to be a Java developer in the first place.</p><p>As to JPA specifically, I've used it since JPA 1.0. Even then, 80%+ of my code used just plain JPA. Things have gotten better since then, which is why folks like Emmanuel can even consider deprecating the native API altogether. JPA certainly provides far more coverage than POSIX.</p><p>If you are trying to suggest open source is an alternative to standards, that's completely a false choice. The goal of open source is transparency, not vendor neutrality. That's why it provides a very weak form of guard against vendor-neutrality. Basically, your only option is forking a large code base, which has seldom worked in practice in open source history. The reality is that open source and standards work effectively together, not the other way round.</p><p>At any rate, I'm glad you outright and honestly stated that you don't care about vendor neutrality beyond at the basic protocol level in the interest of full disclosure. In my experience, most IT decision makers do indeed care about vendor neutrality at the API level and embrace it whenever they can, especially in the Java world.</p><p>Reza Rahman | Java EE/GlassFish Evangelist</p><p>All views voiced are my own, not necessarily Oracle's</p>
  9. Pragmatism - really?[ Go to top ]

    I've always seen the value in vendor-neutrality and why I chose to be a Java developer in the first place.

    Me too. But in reality I'm locked-in with such vendors as Oracle and IBM, that locking myself in with SpringSource is irrevelant.

    If you are trying to suggest open source is an alternative to standards, that's completely a false choice.

    No. I'm trying to suggest that open source is an alternative to vendor lock-in. Or rather an escape from it.

    The goal of open source is transparency, not vendor neutrality.

    I love that word - transparency - really. I miss it in each public tender I'm indirectly involved in...

    Basically, your only option is forking a large code base, which has seldom worked in practice in open source history.

    And I must directly disagree with you. You work for Oracle, so you should remember what happened to Hudson/Jenkins and OpenOffice/LibreOffice. I'm not saying that'd worked just as well with MySQL/MariaDB however...

    In my experience, most IT decision makers do indeed care about vendor neutrality at the API level and embrace it whenever they can, especially in the Java world.

    In my experience (Poland) most IT decision makers follow the simple, universal rule - you won't get fired/blamed for choosing IBM/Oracle/Microsoft. If I were a (real) decision maker, I'd opt for true open source and standards. And you know what? I believe that going full open source (not necessarily FREE SOURCE - the key, as you've mentioned - is transparency) would make sticking to JavaEE APIs easier. But now I just don't believe what my application server provides (I know, I'm boring)

    regards
    Grzegorz Grzybek

  10. Pragmatism - really?[ Go to top ]

    If you look at things carefully/objectively, you'll see that your open source forking examples actually prove my real point. While the open source notion of vendor neutrality often leads to the difficult situation of being forced to port betwen imcompatible implementations, open standards empower you to choose between compatible implementaions when you have to (open source or otherwise). Open source is a great answer to many problems, but not the answer to every problem (just as standards aren't the answer to every problem). For those who desire maximum transparency, the anwer is actually to adopt something that is both open source and open standards whenever possible (which in Java is possible most of the time). In fact standards actually empower you to choose a compatible closed source whe you have to/want to. This hybrid system not limited to open source only is actually a unique core strength of the Java ecosystem that we should all value.<p>Reza Rahman | Java EE/GlassFish Evangelist<p>All views voiced are my own, not necessarily Oracle's.
  11. Pragmatism - really?[ Go to top ]

    For those who desire maximum transparency, the anwer is actually to adopt something that is both open source and open standards whenever possible (which in Java is possible most of the time).

    That's why I chose Java! :)

    In fact standards actually empower you to choose a compatible closed source whe you have to/want to.

    In my (Poland) reality it's rather "have to" option. But you're right - it's better to deploy WAR to JavaEE server than some proprietary solution (are there any left?). But I alo use the following rule: "trust, but control". Translating to JavaEE: "Standards, but WEB-INF/lib" :)

    regards

    Grzegorz Grzybek

  12. Use Hibernate API directly. You'll save yourself a lot of pain in the long run. JEE portability is simply not here for anything non-trivial.