[hibernate-dev] [infinispan-dev] Resetting Lucene lock at Directory initialization

Manik Surtani manik at jboss.org
Mon Oct 19 05:53:24 EDT 2009

On 16 Oct 2009, at 15:50, Sanne Grinovero wrote:

> Hello,
> Lucene does - in default LockManager implementation - a sort of "lock
> cleanup" at index creation: if it detects a lock on the index at
> startup, this is cleared.
> Łukasz translated the exact same semantic on the Infinispan  
> Directory;
> current implementation inserts a "lock marker" at a conventional key,
> like Infinispan was a filesystem.
> So what is done in this case is to just delete the value from this
> key, if any, at startup (for precision: at lockFactory.clearLock()).
> But in this situation I would need to "steal" the lock from another
> node, if it exists. IMHO this Lucene approach is not considering
> concurrent initializations of the FSDirectory.
> So my doubts:
> 1) Is there some API in Infinispan capable to invalidate an existing
> Lock on a key, in case another node is still holding it (and will I
> have the other node failing?)
> 2) Does it make sense at all? looks like a bad practice to steal  
> stuff.
> I am considering to write this lock using SKIP_CACHE_STORE, in which
> case I could assume that if there exists one, there's a good reason to
> not delete the lock as other nodes are running and using the index. In
> case all nodes are going down, the lock doesn't exists as it wasn't
> stored.
> So my proposal is to do a no-op on lockFactory.clearLock(), and use
> SKIP_CACHE_STORE when the lock is created.
> When an IndexWriter re-creates an index (basically making an existing
> one empty) it first uses clearLock(), then it tries to acquire one, so
> it looks like it should be safe.
> WDYT? this concept of SKIP_CACHE_STORE is totally new for me, maybe I
> just misunderstood the usage.

You could use SKIP_CACHE_STORE, but that only means the lock marker  
won't be loaded off disk or some other cache store.  It could still be  
loaded from a neighbouring node.
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache

More information about the hibernate-dev mailing list