Part of 5.2 was merging the JPA contracts into the corresponding Hibernate
ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of
EntityManagerFactory - instead, SessionFactory now extends
EntityManagerFactory.
This caused a few problems that we handled as they came up. In working on
the JPA 2.2 compatibility testing, I see that there are a few more still
that we need to resolve. Mostly they relate to JPA expecting exceptions in
certain cases where Hibernate has historically been lenient. E.g., JPA
says that calling EntityManagerFactory#close on an EMF that is already
closed should result in an exception. Historically, calling
SessionFactory#close on a SF that is already closed is simply ignored.
Philosophical debates aside[1], we need to decide how we want to handle
this situation such that we can throw the JPA-expected exceptions when
needed. Do we simply change SF#close to match the JPA expectation? Or do
we somehow
make SF#close aware of JPA versus "native" use? This latter option was the
intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly
continue to use that as the basis of the solution here for other cases.
This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if
the EMF is created in either of the 2 JPA-defined bootstrap mechanisms,
that flag is set to true. It's an ok solution, but it does have some
limitations - mainly, there was previously a distinction between SF#close
being called versus EMF#close being called (they were different classes, so
they could react differently). Therefore, regardless of bootstrap
mechanism, if the user unwrapped the EMF to a SF, they would always get the
legacy SF behavior.
So long story short, so we want to consider an alternative approach to
deciding what to do in "some"[2] of these cases? Again, we clearly need
these to throw the spec-mandated exceptions in certain "strict compliance"
situations. The question really is how to do that. Should we:
1. just completely change the behavior to align with the spec?
2. change the behavior to match the spec *conditionally*, where that
condition could be:
1. `#isJpaBootstrap`
2. some setting
3. some extension contract
4. something else?
Thoughts?
[1] It's not relevant e.g. that I think JPA is wrong here. We need to
comply with the spec, at least in certain cases ;)
[2] I say "some" here, because I think the spec is correct in some cases -
for example, I think its clearly correct that a closed EMF throws an
exception when `#createEntityManager` is called. Personally I think its
questionable whether closing an already closed EMF should be an exception.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
