Hibernate Search is affected by this, but I thought the current
problem was due to the fact that work is being executed in another
Also, probably :)
We were planning to fix it by collecting the underlying exception
rethrow it to the main thread, or optionally have it logged in case of
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? :)