Thanks Mike.
I'm pretty sure about our mechanism to control one JVM opening the index for
write, but bugs can always be discovered. That's why we used
NativeFSLockFactory - because even if the JVM is killed, the lock file
should be removed. So if we do find the lock, it's fishy (Siamese or not).
B
Currently the sole usage of the LockFactory within Lucene is for the
write.lock, ie, to prevent more than one writer (= IndexWriter, or,
IndexReader trying to do deletions or set norms) from being open on
the index at once.
If your app has external mechanisms that can ensure, without fail,
that on
I have multiple JVMs on different machines accessing the shared file system.
I don't really have multiple IndexWriters on the same JVM, I asked this just
out of curiosity.
So I don't understand from your reply if it's safe to use NoLockFactory, or
I should use SimpleFSLockFactory and unlock if nee
Hi Shai,
> have other uses as well? What about multiple IndexWriters from the same
> JVM?
This also needs a lock. But if it is guaranteed to only have one JVM
accessing the index, you can use an in-JVM-Locking mechanism which is
provided by
http://lucene.apache.org/java/3_0_0/api/all/org/apache/l
Hi
We've run into problems w/ LockFactory usage on our system. The problem is
that the system can be such that the index is configured on a local file
system, or a remote, shared one. If remote/share, the protocol is sometimes
SMB 1.0/2.0, Samba, NFS 3/4 etc. In short, we have no control on the FS
