lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <>
Subject [jira] Commented: (LUCENE-1877) Improve IndexWriter javadoc on locking
Date Mon, 31 Aug 2009 03:25:34 GMT


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:
>             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:
For additional commands, e-mail:

View raw message