On Wed, Apr 29, 2015 at 8:21 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
Yes, I think that logic is not correct. A bigger concern I have
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
On Tue, Apr 28, 2015 at 4:32 PM, Gunnar Morling <gunnar(a)hibernate.org>
> 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(a)hibernate.org>:
>> Where does that wrapping happen?
>> On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gunnar(a)hibernate.org>
>>> while working on making OGM work with ORM 5, I noticed a slightly
>>> 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
>>> (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
>>> Anyone thinking it's a problem?
>>> hibernate-dev mailing list