Difference between EclipseLink and Hibernate for long running sessions (Vaadin 7 and JPAContainer)

Question

Although I need this answer to better understand how I can integrate Vaadin 7 and the JPAContainer addon in Wildfly 8.1, this is a general question that applies to Hibernate and Eclipse-link JPA implementations.

JPACaontainer Vaadin Addon recommends to have an EntityManager for the whole servlet-session, this IMO is not good design because AFAIK (and please correct me) to scale it will always be better to use stateless EntityManager-Per-Request pattern

JPAContaner Addon states that:

1. Hibernate can not keep entity managers for long without problems.
2. One issue with Hibernate is that it is designed for short-lived sessions, but the lifetime of an entity manager is normally roughly that of a user session (read, servlet session). The problem is that if an error occurs in a session or an entity manager, the manager becomes unuseable. This causes big problems with long-lived sessions that would work fine with EclipseLink.

What is the difference between Hibernate and EclipseLink, at the implementation level that makes those two statements be true? OR, are those two statements sill valid in the first place?

Answer 1

I can only speak for Hibernate, so here are my thoughts:

• Hibernate supports long-conversations and you can choose to work with

  • "detached objects"
  • "extended Session" (a Hibernate Session that's disconnected from DB, yet it's not closed)

  The optimistic locking mechanism will prevent losing updates so the shorter the conversation the less chances of stale exceptions.

  If any constraint violation is being thrown the Session is indeed unusable which makes the "extended Session" more fragile than working with "detached entities".

  With detached objects you keep a reference to those entities you plan on managing throughout your conversation and only reattach them (or merge them) when the workflow is over.

• According to Hibernate Session docs :

  If the Session throws an exception, the transaction must be rolled back and the session discarded. The internal state of the Session might not be consistent with the database after the exception occurs.

  If the internal Session state can't be synchronized to the database any more (because of Constraint Violation Exceptions or Optimistic locking exceptions) the Session is no longer usable and you'll have to restart a new clean Session. Otherwise you keep on receiving the save exceptions as long as the current entities are stale or have invalid data.

  One alternative would be to clear the Session and discard all your current pending changes that end up throwing exceptions, or refresh the failing entities.

I wonder how EclipseLink manages to work in these scenarios, as a broken Session is not always recoverable, like when you have stale data and refreshing would mean "loosing updates".