[hibernate-dev] Changes around transaction -> changed exception behavior

Steve Ebersole steve at hibernate.org
Wed Apr 29 09:21:50 EDT 2015


Yes, I think that logic is not correct.  A bigger concern I have there tbh
is HEM; there is some very fragile (at best) code that tries to "decode"
the exceptions thrown by the native APIs.  That stuff could very easily
break.

On Tue, Apr 28, 2015 at 4:32 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> TransactionImpl#commit(); The before-completion code is now invoked
> through transactionDriverControl.commit(); whereas previously this
> happened out of a try/catch block.
>
> 2015-04-28 23:26 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Where does that wrapping happen?
>>
>> On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>>  Hi,
>>>
>>> while working on making OGM work with ORM 5, I noticed a slightly
>>> different
>>> behaviour wrt. to exceptions occurring during flushes.
>>>
>>> Previously, such exceptions would bubble up as is, whereas now the
>>> beforeTransactionCompletion() logic is called in a try/catch block,
>>> wrapping any exceptions in a TransactionException. It's no big deal for
>>> me
>>> (I just need to adapt some tests in our suite which expect specific
>>> exception types), but then I was wondering whether that change poses a
>>> migration issue for existing client code, e.g.
>>> expecting/handling StaleObjectStateException which would need to be
>>> adapted
>>> accordingly?
>>>
>>> Anyone thinking it's a problem?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>


More information about the hibernate-dev mailing list