The main reason is because allowing these exceptions to be
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.