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
