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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
