Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Message-ID: <22234657.50931277429330331.JavaMail.jira@thor>
Date: Thu, 24 Jun 2010 21:28:50 -0400 (EDT)
From: "Marvin Humphrey (JIRA)" <jira@apache.org>
To: lucy-dev@lucene.apache.org
Subject: [jira] Resolved: (LUCY-119) Lucy::Store::Lock
In-Reply-To: <18334335.6991277258870416.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LUCY-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marvin Humphrey resolved LUCY-119.
----------------------------------

    Resolution: Fixed

Committed as r957776.

> Lucy::Store::Lock
> -----------------
>
>                 Key: LUCY-119
>                 URL: https://issues.apache.org/jira/browse/LUCY-119
>             Project: Lucy
>          Issue Type: New Feature
>          Components: Core - Store
>            Reporter: Marvin Humphrey
>            Assignee: Marvin Humphrey
>            Priority: Blocker
>         Attachments: lock.patch
>
>
> This patch provides four classes:
>   * Lock - abstract base class
>   * LockFileLock - implementation of Lock using lockfiles.
>   * SharedLock - read locks.
>   * LockErr - Subclass of Err allowing users to catch locking exceptions.
> The lockfiles are encoded as JSON and contain both a PID and a host.  Lock's
> Clear_Stale() method will only zap lockfiles if "host" matches and the PID is
> inactive.  However, the default for "host" is empty string, since working on a
> shared volume is not the common case and we don't want to force everyone to
> supply it all the time.  Omitting host is perfectly safe for indexes on local
> volumes, but it's an unsafe default for applications designed to work with shared
> volumes; such apps must be careful that each machine is supplies a unique
> value for "host".
> This locking implementation of also provides support for read locks.  Right
> now, each read lock is a separate file.  In the future, we should change this
> to use hard linking instead, drawing on algorithms from the Linux liblockfile
> package.
> A native implementation of Lock is theoretically possible if the system
> supports true flock() semantics, including refcounting.  However, certain
> systems (e.g.  Solaris) fake up flock() support using fcntl() locks -- and
> fcntl() locks have terrible behavior under fork().
> Lucene today uses native locking by default.  The implementation has been
> carefully worked out so that it works under fcntl semantics, and it is assumed
> that nobody's going to fork() a Lucene process:
> [https://issues.apache.org/jira/browse/LUCENE-1877?focusedCommentId=12749363&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12749363]
> Lucy in contrast, absolutely must support fork(), so it cannot default to
> using native locks when fcntl semantics are in effect.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.