[hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager
Steve Ebersole
steve at hibernate.org
Sat Apr 30 10:06:08 EDT 2016
We are seeing this too in your documentation tests. So its ok to just
change those to wrap the writes/flushes in a transaction? (they are not
now)
On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:
> 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.
>>
>>
>
More information about the hibernate-dev
mailing list