[hibernate-dev] Resetting Lucene lock at Directory initialization

Sanne Grinovero sanne.grinovero at gmail.com
Fri Oct 16 10:50:38 EDT 2009


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.

Regards,
Sanne




More information about the hibernate-dev mailing list