(extracted from issue 665 (turned to be non related to that
issue).)
In NFS or other shared fs situations, Locks are maintained
in a specified
folder, but a lock file name is derived from the full path
of the index
dir, actually the canonical name of this dir. So, if the
same index is
accessed by two machines, the <drive> / <mount>
/ <fs> root of that index
dir must be named the same in all the machines on which
Lucene is invoked
to access/maintain that index.
Since File.getCanonicalPath() is system dependent, and since
sometimes even
for the same type of OS the mount names differ, Lucene has
the
setLockPrefix() API that allows users to configure locks
prefix path in
each machine.
This seems like a source for possible problems, when users
mis configure
their lock prefixes. - if the index path was not configured
correctly, the
index would not be found, and this is likely to be found and
fixed pretty
soon. But if lock path prefixes are misconfigured, chances
are that the
index would get corrupted.
This would be avoided if index locks are maintained in the
index folder. I
searched the lists for previous discussions on this 'design
decision' -
i.e. where the index locks reside - found none. Wouldn't it
simplify
matters to have the locks in the index dir? Any
disadvantages of this?
Thanks,
Doron
------------------------------------------------------------
---------
To unsubscribe, e-mail: java-dev-unsubscribe lucene.apache.org
For additional commands, e-mail: java-dev-help lucene.apache.org
|