lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-305) [PATCH] Lock Framework - allows custom lock mechanism
Date Thu, 31 Aug 2006 02:26:24 GMT
    [ ] 
Michael McCandless commented on LUCENE-305:

I think we can close this issue now that LUCENE-635 is resolved.

> [PATCH] Lock Framework - allows custom lock mechanism
> -----------------------------------------------------
>                 Key: LUCENE-305
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: unspecified
>         Environment: Operating System: other
> Platform: All
>            Reporter: Jeff Patterson
>         Assigned To: Lucene Developers
>            Priority: Minor
>         Attachments:, FSDirectory_patch_file.txt,, Lock_patch_file.txt,,
> Proposal:  Pluggable Lock Framework for Lucene
> Date:      Nov 2004
> Developer: Jeff Patterson ( -
> ------
> Abstract:  A framework to allow Lucene users to override the default
> FileSystem locking mechanism with a custom lock mechanism.
> A Lucene user may develop a new class that extends 
> and implement bodies for the following
> methods:
>     public boolean obtain()    - to obtain custom lock
>     public boolean isLocked()  - to detect custom lock
>     public void release()      - to release custom lock
> NOTE: When implementing these methods, the developer should make sure to 
> use the this.getLockName() method on the Lock to identify which lock
> is being manipulated (see Modified Files below for more).
> After developed, the new class must be added to the classpath (along
> with any other supporting classes/libraries needed by the new class),
> and the Lucene framework must be alerted of the new class by way of
> the "org.apache.lucene.lockClass" -D System property.  Example:
>    java -Dorg.apache.lucene.lockClass=foo.MyCustomLocker LuceneTest
> ------
> Modified Files:  The following files were modified to support 
> this framework (DIFF files at end):
> -
>   The member "lockName" and an accompanying protected getter and
>   setter were added to this class to support naming the lock.  This
>   is transparent to the default lock mechanism and is only useful
>   when writing a custom lock.
> -
>   Instead of instantiating a default Lock, this class now checks
>   to see if an overridden Lock mechanism is provided, and if so
>   asks the LockFactory (see below) to provide an overridden Lock
>   class.
> New Files:  The following files were added to support this framework:
> -
>   This class is used to reflect and instantiate by name the custom
>   Lock implementation.  Error handing should be modified in this
>   class, but that would have required a more extensive code overhaul.
>   The javadocs for the LockFactory contain a skeleton Java file for
>   a custom lock implementation.
> ------

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message