[hibernate-dev] Exceptions thrown in a tx synchronization are eaten

[Hernán Chanfreau]

Hi!

The sync is actually rolling back the main transaction, but there is no way
to indicate upper layers about it because hibernate calls commit()
succesfully after syncs.
Could we think about adding a new exception to be throwed by the
JDBCTransaction? In that case this exception is thrown by a sync that needs
to rollback the main transaction (like envers sync). And a new catch block
has to be added in
JDBCTransaction.notifyLocalSynchsBeforeTransactionCompletion() and re-throw.

Thanks. Hernán.


2010/3/29 Steve Ebersole <steve at hibernate.org>

> The main reason is because allowing these exceptions to be (re-)thrown
> opens up mixed heuristic issues.
>
> Also bear in mind that we have no clue about the nature of the process
> being performed by the synch.  It highly likely that "failure" of the
> synch should *not* rollback the main transaction.  This is really one of
> the 50/50 data points.  We really just do not know, and the contract
> gives us no way to know.  However, if rolling back is that important it
> is in fact possible in any case i can imagine to pass the
> o.h.Transaction into the Synchronization constructor and actually roll
> it back if an error occurs.
>
>
> On 03/24/2010 03:54 PM, Adam Warski wrote:
> > Hello,
> >
> > if a transaction synchronization throws an exception, is it only logged,
> and not thrown further (see org.hibernate.transaction.JDBCTransaction, line
> 273). Is there some reason for this?
> >
> > As Envers uses tx synchronizations quite extensively, when an exception
> is thrown in the synchronization, I roll back the transaction manually. So,
> no data is persisted (which is the desired behavior), but the client isn't
> notified in any way that something went wrong; for the client, the operation
> behaves as if the tx commited successfully.
> >
> > I suspect that maybe some applications rely on the fact that the
> exception is eaten and not re-thrown. If there are no contra-arguments to
> throw the exceptions, maybe a good solution would be to re-throw the
> exception is the transaction is already marked for rollback? Or if it was
> marked for rollback in the synchronization?
> >
> > The related JIRA issues are:
> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3543
> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-4721
> >
> > By the way, how does Hibernate Search deal with such situations? I looked
> at PostTransactionWorkQueueSynchronization, and it seems that it's possible
> that the transaction commits, but the data isn't indexed properly, if the
> queueingProcessor.performWorks throws an exception?
> >
>
> --
> steve at hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>