lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Updated: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors &
Date Wed, 02 Sep 2009 17:28:33 GMT


Uwe Schindler updated LUCENE-1877:

    Attachment: LUCENE-1877.patch

Here is the patch:
- SimpleFSLockFactory and NativeFSLockFactory now have the same abstract superclass providing
setLockDir and getLockDir. Using this method, it is possible for directory instances to detect,
if the locks reside in the directory itsself and so a lock prefix is switched off.
- The isLocked() bug in NativeFSLockFactory (LUCENE-1885) is solved by implementing what was
described in this issue.

I have one idea (which is  a new feature): How about providing a ctor to NativeFSLockFactory
and SimpleFSLockFactory without param. When this LF is added to a FSDir, it would default
to set the LockDir to itsself (if lf.getLockDir()==null) lf.setLockDir( This
would prevent users from always giving the directory twice? Any thoughts, I would like to
have that.

Because of the missing lockPrefix for locks inside the directory itsself one backwards test
(TestLockFactory) must be changed in backwards-branch, too.

> Use NativeFSLockFactory as default for new API (direct ctors &
> --------------------------------------------------------------------------
>                 Key: LUCENE-1877
>                 URL:
>             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
> 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:
For additional commands, e-mail:

View raw message