[hibernate-dev] Resetting Lucene lock at Directory initialization

[Emmanuel Bernard]

Sanne, please don't use closed mailing lists, emails are bounced back  
and that's annoying.
PS: removing source sense's ML

On 16 oct. 09, at 16: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.
>
> Regards,
> Sanne
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev