[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749363#action_12749363
]
Marvin Humphrey commented on LUCENE-1877:
-----------------------------------------
> I can see how this is not ideal, but I'm not seeing how any of the
> mentioned issues apply to our simple lock usage ...
"Simple lock usage"?! You must have a bigger brain than me...
As a matter of fact, I think you're right. Fcntl locks have two major
drawbacks, and upon review I think NativeFSLockFactory avoids both of them.
The first is that opening and closing a file releases all locks for the entire
process. Even if you never request a lock on the second filehandle, or if you
request a lock and the request is denied, closing the filehandle releases the
lock on the first filehandle. But NativeFSLockFactory avoids that problem by
keeping the HashSet of filepaths and ensuring that the same file is never
opened twice. Furthermore, since the lockfiles are private to Lucene, you can
assume that nobody else is going to open them and inadvertently spoil the lock.
The second is that child processes spawned via fork() do not inherit locks
from the parent process. If you assume that nobody's ever going to fork a
Java process, that's not relevant. (Too bad that won't work for Lucy... we
have to support fork().)
I think you're probably safe with Fcntl locks on all non-shared volumes.
> Improve IndexWriter javadoc on locking
> --------------------------------------
>
> Key: LUCENE-1877
> URL: https://issues.apache.org/jira/browse/LUCENE-1877
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Javadocs
> Reporter: Mark Miller
> Priority: Trivial
> Fix For: 2.9
>
>
> 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
