Hi,
It's fine if we stick to the JPA spec so that only read ops are allowed to
be executed outside of a transactional context. Most applications use
either Java EE or Spring, so transaction boundaries are usually enforced
anyway.
It's also fine to throw an exception if the object being checked within the
Persistence Context is not an entity. This might break some existing use
cases, but we are covered by the JPA spec :D
In the getTransaction() case, I still believe we should offer two
strategies: a JPA and a native one, the choice being made based on the
current bootstrap procedure or some configuration property.
Vlad
On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
2. "Another change in expectation is in regards to operations
outside of
> a transaction" - in JPA we can execute queries outside a transaction,
> but any write will fail if there is no transactional context, which is
> reasonable for me too. If Hibernate allows writes outside of a
> transactional context, that's definitely a thing we should not support
> anyway.
>
Well we'll agree to disagree about the validity of allowing queries
outside the scope of a transaction; it does not matter, because JPA says it
should be allowed, so we have to allow that.
However, historically Hibernate allowed writes outside the scope of a
transaction as well (auto-commit support), so that is what I am talking
about. After pulling over HEM logic we now have some test failures due to
tests trying to write data outside of an explicit transaction (
javax.persistence.TransactionRequiredException).
So I propose we continue to expect that as a failure starting in 5.2. For
queries we will continue to supports it, but only because JPA requires us
to; not because it is a valid concept.
> 3. "Asking a Session if is contains (Session/EntityManager#contains) a
> non-entity" - we can handle this with the separate exception handler
> strategies to retain both JPA and Hibernate behaviors.
>
Why? This is exactly the kind of thing I have in mind when I talk about
the unnecessary complexity. Clearly asking if the Session contains a
boolean e.g. is complete non-sense. If JPA requires that condition to
throw an exception, why even worry about the other case?
> 4. "Accessing Session/EntityManager#getTransaction. JPA says that is
> only allowed for JDBC transactions. Hibernate always allows it." - I'd
> choose the Hibernate behavior because I don;t see how it can cause any
> issue and it's an enhancement as well.
>
Well that's great in principle. But JPA actually requires an exception be
thrown when #getTransaction() is called in the JTA case. So there is no
simple "just allow it as an extension" solution, we'd have to specific
allow users to opt-in to allowing that.