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@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
