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