lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] Closed: (LUCENE-305) [PATCH] Lock Framework - allows custom lock mechanism
Date Thu, 31 Aug 2006 02:31:25 GMT
     [ http://issues.apache.org/jira/browse/LUCENE-305?page=all ]

Yonik Seeley closed LUCENE-305.
-------------------------------

    Fix Version/s: 2.0.1
       Resolution: Duplicate
         Assignee: Yonik Seeley  (was: Lucene Developers)

> [PATCH] Lock Framework - allows custom lock mechanism
> -----------------------------------------------------
>
>                 Key: LUCENE-305
>                 URL: http://issues.apache.org/jira/browse/LUCENE-305
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: unspecified
>         Environment: Operating System: other
> Platform: All
>            Reporter: Jeff Patterson
>         Assigned To: Yonik Seeley
>            Priority: Minor
>             Fix For: 2.0.1
>
>         Attachments: FSDirectory.java, FSDirectory_patch_file.txt, Lock.java, Lock_patch_file.txt,
LockFactory.java, MySQLLocker.java
>
>
> Proposal:  Pluggable Lock Framework for Lucene
> Date:      Nov 2004
> Developer: Jeff Patterson (jeffATwebdoyen.com - http://www.webdoyen.com)
> ------
> 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 
> org.apache.lucene.store.Lock 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):
> - org.apache.lucene.store.Lock
>   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.
> - org.apache.lucene.store.FSDirectory
>   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:
> - org.apache.lucene.store.LockFactory
>   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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message