Hello,
if a transaction synchronization throws an exception, is it only logged, and not thrown
further (see org.hibernate.transaction.JDBCTransaction, line 273). Is there some reason
for this?
As Envers uses tx synchronizations quite extensively, when an exception is thrown in the
synchronization, I roll back the transaction manually. So, no data is persisted (which is
the desired behavior), but the client isn't notified in any way that something went
wrong; for the client, the operation behaves as if the tx commited successfully.
I suspect that maybe some applications rely on the fact that the exception is eaten and
not re-thrown. If there are no contra-arguments to throw the exceptions, maybe a good
solution would be to re-throw the exception is the transaction is already marked for
rollback? Or if it was marked for rollback in the synchronization?
The related JIRA issues are:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3543
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4721
By the way, how does Hibernate Search deal with such situations? I looked at
PostTransactionWorkQueueSynchronization, and it seems that it's possible that the
transaction commits, but the data isn't indexed properly, if the
queueingProcessor.performWorks throws an exception?
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu