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

[Vlad Mihalcea]

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 at 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.
>
>