MassIndexer causes a LockObtainFailedException to be thrown when using Infinispan as a directory provider


When using MassIndexer and FSDirectory all is okay. When using InfinispanDirectory LockObtainFailedException is thrown.

A test case is attached (MassIndexerTest).

Note that for this test a slightly modified copy of InfinispanDirectoryProvider was needed, as the Infinispan cache instance we use in production is declared in Spring.


Hibernate Core 3.6.5/Hibernate Search 3.4.0/Infinispan 5.0/Spring 3.0.5


Sanne Grinovero
September 2, 2011, 4:49 PM

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.

September 6, 2011, 5:36 PM

I changed each named cache for Lucene to use org.infinispan.transaction.lookup.DummyTransactionManagerLookup and the test passed. Is this what you meant for decoupling the cache from the transaction manager?

Sanne Grinovero
September 6, 2011, 5:53 PM

Hi Tom,
I actually meant that it should be not transactional, but that should be fine as what you did is - with the current Infinispan implementation - totally equivalent, as Infinispan will use the DummyTransactionManager when transactions are disabled and batching is enabled.

Sanne Grinovero
September 7, 2011, 1:18 AM

to clarify my previous comment: in short yes what you did is correct.

An alternative solution is to not define the transactionManager configuration in the default cache, so that it won't be inherited by other caches and configure it only on those caches which are not being used to store Lucene's index. What you did though obtains the same end result.

Yoann Rodière
May 18, 2020, 10:04 AM

Closing as out of date as this will no longer be relevant in Infinispan 12 / Search 6: there will no longer be an Infinispan directory provider.







Suitable for new contributors


Pull Request


Feedback Requested



Affects versions