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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev