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

[Emmanuel Bernard]

I tend to agree. The problem today is that you cannot forward / signal the exception to the upper levels.

In an ideal world, a Synchronization should swallow exceptions (or do whatever it wants with it) if the exception should not tamper with the main Hibernate execution. In a word, Synchronization would be in control. It has my preference but It's a change of semantic.

Adam's solution of rethrowing if the tx is marked for rollback is less invasive but I find that a bit too magic.

I am not a big fan of Hernán's solution as it forces the synchro to raise a specific exception and it does not work in JTA as Hibernate is no longer in control.

On 29 mars 2010, at 22:17, Adam Warski wrote:

> Hello,
> 
>> 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.
> 
> Right. Then I was thinking about two solutions:
> 1) as Hernan wrote above
> 2) check if the TX wasn't rolled back by the synchronization (tx.isMarkedForRollBack or sth similar) explicitly. If so, rethrow the exception.
> 
> -- 
> Adam Warski
> http://www.warski.org
> http://www.softwaremill.eu
> 
> 
> 
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev