lucy-dev mailing list archives

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

                 Key: LUCY-119
             Project: Lucy
          Issue Type: New Feature
          Components: Core - Store
            Reporter: Marvin Humphrey
            Assignee: Marvin Humphrey
            Priority: Blocker

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

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