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
