https://hibernate.atlassian.net/browse/HHH-9760
On Wed, Apr 29, 2015 at 8:21 AM, Steve Ebersole <st...@hibernate.org> wrote: > 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 <gun...@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 <st...@hibernate.org>: >> >>> Where does that wrapping happen? >>> >>> On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gun...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
