> 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
