Use hibernate sessionFactory or JPA entityManager?

Question

I'm working on a project that uses Hibernate 4.1, Spring 3.1, and JPA 2.0, and I want to verify that what I've gleaned from the internet is correct.

I'm trying to decide whether to use a JPA entityManager or the hibernate-specific sessionFactory.

At first I planned to use entityManager and full JPA specifications, so my project would be decoupled from Hibernate, and I could switch it out for something else, say EclipseLink, if the fancy took me or something convinced me later on.

However, it seems the entityManager has some very significant limitations.

My questions:

The only reason I would want to use full JPA specifications and the entityManager is to be able to switch out Hibernate for a different JPA 2.0 compatible ORM relatively easily, right? Are there really no performance / functionality / ease of programming benefits to using the entityManager?

Second, it seems like the hibernate sessionFactory has a lot of benefits over the entityManager. So far I've run into the issue that the entityManager can't perform a batch insert of a list of entities, which I've read the sessionFactory can. I've also read that the sessionFactory can return an auto-generated entity ID automatically, while with the entityManager you need to end the transaction / flush the persistence context to pull the newly generated id.

I liked the idea of my project being relatively decoupled from Hibernate, but I would much rather be able to write efficient database updates from the get-go. So I should switch over to my project being configured for hibernate and the sessionFactory, right?

Answer 1

I would stick to JPA2, like you would use List rather than ArrayList: you favour the interface (or abstract) over the implementation. There are not much difference, apart from HQL knowing "more" stuff than JPQL or exotic feature. Also remember that JPA was made after Hibernate, with Hibernate being the "inspiration" behind JPA.

And for exotic feature: Hibernate Entity Manager wrap an Hibernate Session. If you really need them, you can cast the EntityManager to the Hibernate interface (org.hibernate.jpa.HibernateEntityManager), and use that session. But I'd be lying to you if I say I tried it.

I also commented part of your question:

The only reason I would want to use full JPA specifications and the entityManager is to be able to switch out Hibernate for a different JPA 2.0 compatible ORM relatively easily, right? Are there really no performance / functionality / ease of programming benefits to using the entityManager?

Switching from Hibernate to EclipseLink does not mean you "only need to swap the jar". The mapping, and annotation parsing, is not the same and you'll encounter problems that will probably discourage you from switching.

You can read my question here for an example of a problem I encountered while using both (it was a maven project with a profile to switch JPA2.1 impl from EclipseLink to Hibernate). I dropped EclipseLink because I could not name the database object (or rather, specify the name of database object) like I wanted.

Second, it seems like the hibernate sessionFactory has a lot of benefits over the entityManager. So far I've run into the issue that the entityManager can't perform a batch insert of a list of entities, which I've read the sessionFactory can. I've also read that the sessionFactory can return an auto-generated entity ID automatically, while with the entityManager you need to end the transaction / flush the persistence context to pull the newly generated id.

This depends on how you generate your entity id. But think about it: you entity is not persisted until the persistence context need to persist it. This is the reason you don't have an id. Flushing it, aka sending an insert query with a generated id, is the only way to do it.

The same apply to session factories.

You might however be able to access a sequence generator from Hibernate, but you can also do that in native SQL with EntityManager.

I liked the idea of my project being relatively decoupled from Hibernate, but I would much rather be able to write efficient database updates from the get-go. So I should switch over to my project being configured for hibernate and the sessionFactory, right?

You can take it as a troll against ORM, but for efficient database update, use plain JDBC (or Spring Jdbc Template). At least you'll know when data will be updated, and you'll be able to better optimize (batch update, etc).

Answer 2

JPA is an interface over Hibernate which is an interface over jdbc so the closer you are to jdbc the more control you get over your queries but further you go from object/relational persistence . Yes, Hibernate may have some tools that jpa may not provide at this moment (i.e hibernate spatial) Hibernate is fun and can use JPA annotations for mapping the domain model (if you go the annotations way over the .hbm files) . And the way the @Transactional annotation works in Spring it doesnt matter whether you use hibernate or jpa since you dont need session.open() ... session.beginTranscation ...session.close ...etc ... all this verbose Hibernate code is gone! There is great documentation on Hibernate and greate books as well. As for JPA I cant say that I found the umber book...