[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780647#action_12780647
]
Marvin Humphrey commented on LUCENE-1877:
-----------------------------------------
> http://www.h2database.com/html/advanced.html#file_locking_protocols
I'm a little concerned about the suitability of the polling approach for a
low-level library like Lucene -- shouldn't active code like that live in the
application layer? Is it possible to exceed the polling interval for a low
priority process on a system under heavy load? What happens when the app
sleeps?
For removing stale lock files, another technique is to incorporate the host
name and the pid. So long as you can determine that the lock file belongs to
your machine and that the PID is not active, you can safely zap it.
Then tricky bit is how you get that information into the lock file. If you
try to write that info to the lock file itself after an O_EXCL open, creating
a fully valid lock file is no longer an atomic operation.
The approach suggested by the creat(2) man page and endorsed in the Linux NFS
FAQ involves hard links:
{noformat}
The solution for performing atomic file locking using a lockfile
is to create a unique file on the same file system (e.g.,
incorporating hostname and pid), use link(2) to make a link to the
lockfile. If link() returns 0, the lock is successful. Otherwise,
use stat(2) on the unique file to check if its link count has
increased to 2, in which case the lock is also successful.
{noformat}
This approach should also work on Windows for NTFS file systems since Windows
2000 thanks to the CreateHardLink() function. (Samba file shares, you're out
of luck.) However, I'm not sure about the state of support for hard links in
Java.
If you're interested in continuing this discussion, we should probably take it
somewhere other than this closed issue.
> Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
> --------------------------------------------------------------------------
>
> Key: LUCENE-1877
> URL: https://issues.apache.org/jira/browse/LUCENE-1877
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Javadocs
> Reporter: Mark Miller
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch,
> LUCENE-1877.patch
>
>
> A user requested we add a note in IndexWriter alerting the availability of
> NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm
> exit). Seems reasonable to me - we want users to be able to easily stumble
> upon this class. The below code looks like a good spot to add a note - could
> also improve whats there a bit - opening an IndexWriter does not necessarily
> create a lock file - that would depend on the LockFactory used.
> {code} <p>Opening an <code>IndexWriter</code> creates a lock file for the
> directory in use. Trying to open
> another <code>IndexWriter</code> on the same directory will lead to a
> {...@link LockObtainFailedException}. The {...@link
> LockObtainFailedException}
> is also thrown if an IndexReader on the same directory is used to delete
> documents
> from the index.</p>{code}
> Anyone remember why NativeFSLockFactory is not the default over
> SimpleFSLockFactory?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
