lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <>
Subject [jira] Updated: (LUCY-119) Lucy::Store::Lock
Date Wed, 23 Jun 2010 02:09:50 GMT


Marvin Humphrey updated LUCY-119:

    Attachment: lock.patch

> Lucy::Store::Lock
> -----------------
>                 Key: LUCY-119
>                 URL:
>             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:
> []
> 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.

View raw message