[hibernate-dev] Exceptions thrown in a tx synchronization are eaten

[Adam Warski]

> interesting,
> Hibernate Search is affected by this, but I thought the current
> problem was due to the fact that work is being executed in another
> thread.
Also, probably :)

> We were planning to fix it by collecting the underlying exception and
> rethrow it to the main thread, or optionally have it logged in case of
> async work:
> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-421
Well, even if you rethrow it in the transaction synchronization it will only get logged, but the client won't know anything.

> Emmanuel made a great point in the book about the fact that you
> probably don't want to rollback your business operations on the
> database in case of indexing failures - I totally agree with that, so
> that sets Search in a special corner regarding this.
Well, hmm, guess that depends on the use-case, sometimes it's true that I may not want to rollback the whole TX in case of an indexing failure, but in most cases I guess I wouldn't want for the indexes to go out-of-sync. Depends on how important the search results are :).

Anyway, I think it may be a good idea to let the client know that something bad has happened. Or at least give him an option to let him know.

So, any opinions pro/con to changing the org.hibernate.transaction.JDBCTransaction? :)

-- 
Adam Warski
http://www.warski.org
http://www.softwaremill.eu