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





_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to