[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-893) MassIndexer causes a LockObtainFailedException to be thrown when using Infinispan as a directory provider

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-893?pag... ] Sanne Grinovero commented on HSEARCH-893: ----------------------------------------- This is a nasty timing situation. It happens on Infinispan only because it's quite faster than a FSDirectory in acquiring the IndexWriter lock, and since Hibernate Search's transactional backend is async and was queued quite some work, when the MassIndexer acquires the lock the transactional backend is still busy. This shouldn't normally be an issue, as the timing different is less than a millisecond, but wasn't detected before as we usually test on FS. Unfortunately reconfiguring the LockFactory to provide a longer timeout is not a solution: Lucene's Lock implementation polls the cache state each second and is not notified that the value is actually released very quickly, so at a minimum the polling period should be set too, but with this Infnispan configuration polling will fail: As the backend attempts to aquire the lock, Infinispan will implicitly start a transaction as this was configured this way, and then you get repeatable read semantics too, which prevents the Lock implementation to _see_ the lock as released: the polling strategy from o.a.l.Lock will look over and over but will never receive a different value. Solution: don't couple the Infinispan cache storing the index to the transaction manager. There is no downside either, I'll update the documentation to recommend this. Also this issue doesn't affect Hibernate Search 4.x as it doesn't contend any lock between the two backends: the IndexWriter is shared. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira