[hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager

[Steve Ebersole]

There are a number of "expectation changes" that come about from
consolidating hibernate-entitymanger into hibernate-core.  Some we have
discussed; some we have not.  Hopefully we can come to a consensus regards
how to deal with these changes...

The first one is different exception types.  We have discussed this
before.  For now, in an effort to fix test failures and move forward with
developing, I simply changed failing tests to expect the JPA defined
exceptions.  I had mentioned, where possible, to to throw a combination of
the 2 expected exceptions.  Generally this falls into 2 discrete categories:


   1. JPA expects a PersistenceException and we have historically thrown a
   HibernateException
   2. JPA expects some form of JDK RuntimeException
   (IllegalArgumentException, IllegalStateException, etc) and we have
   historically thrown a HibernateException

It is unfortunate that Java does not allow exceptions to be defined by
means of interfaces; that's the only "clean" way I see to do this - that
would have allowed us to define concrete exception classes that extend
PersistenceException, IllegalArgumentException, etc and that implement
HibernateException.


So I see 3 potential solutions (feel free to bring up others).

   1. Just move to JPA expected exceptions.
   2. Have HibernateException extend PersistenceException and just not
   worry about the change in expectation in regards to that second category.
   3. Push exception handling behind a strategy.  This would have to be a
   pretty specific strategy for very specific cases.

The first and second options are pretty self-explanatory and
straight-forward so I won't go into detail there.  Just realize that these
change the expectation for the user.  They'd have to change their code to
catch these JPA-defined exceptions.
The other option, I see, is to h

The third option is perfect in theory, but it is very tedious.  For
example, take the case of trying to perform some operation on a closed
Session/EntityManager.  Hibernate historically threw a HibernateException
here.  JPA says that should result in an IllegalStateException.  So in
SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd call
out to the strategy to handle that condition.  Even more, Hibernate
(historically) and JPA disagree about which methods getting called on a
closed Session/EntityManager should lead to an exception.  For example, JPA
says calling EntityManager#close on a closed EntityManager should result in
an exception; Hibernate historically did not care if you called
Session#close on a closed Session.  So that is a special case, and every
one of those special cases would have to be exposed and handled in the
exception handling strategy in additional to the general cases.

Another change in expectation is in regards to operations outside of a
transaction, which I consider a questionable pattern anyway.  Hibernate
historically allowed that; JPA explicitly disallows it.  In a way this
could fall under the exception discussion above, meaning we could push that
distinction behind the exception handling strategy.  Or we could decide
that we are going to stop supporting that.

There are a lot of other highly questionable things I have seen in the
tests that JPA explicitly disallows that I think we ought to just stop
supporting and opt for the JPA way, although I am open to discussing them
if any feels strongly about them.  Some of these include:

   - Asking a Session if is contains (Session/EntityManager#contains) a
   non-entity.  Hibernate historically would just return false.  JPA states
   that should be an exception.
   - Accessing Session/EntityManager#getTransaction.  JPA says that is only
   allowed for JDBC transactions.  Hibernate always allows it.

If we go the route of an "exception handling strategy" a lot of the other
points I mentioned above could just be pushed behind that strategy.  But I
really want to start looking critically at what we support today that we
maybe really should not be.