[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780540#action_12780540
]
Thomas Mueller commented on LUCENE-1877:
----------------------------------------
FYI: other Java projects also implement exclusive locking, and automatic
removal of such a file.
Apache Jackrabbit uses FileChannel.lock() by default, but there are problems
with some NFS implementations (some don't release the lock after restart, some
don't support locks at all). Also, some operating systems / file systems allow
multiple write locks within the same process (possibly in different class
loaders). Jackrabbit works around that by (mis-)using a system property. See
http://wiki.apache.org/jackrabbit/RepositoryLock
For the H2 Database Engine I implemented a cooperative locking mechanism:
http://www.h2database.com/html/advanced.html#file_locking_protocols - I have
also ported that to Apache Jackrabbit ("Cooperative File Lock Mechanism"). It
always works, but needs a background thread. H2 also supports a mechanism based
on a server socket (open a server socket and write the IP address and port to
the file) - but this is problematic if the network is misconfigured (localhost
not bound to 127.0.0.1 and such) which does happen in practice.
> 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
