FAQ
[ http://issues.apache.org/jira/browse/LUCENE-305?page=comments#action_12427015 ]

Michael McCandless commented on LUCENE-305:
-------------------------------------------

See LUCENE-635 which subsumes this patch.
[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: Lucene Developers
Priority: Minor
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

Search Discussions

  • Michael McCandless (JIRA) at Aug 9, 2006 at 7:42 pm
    [ http://issues.apache.org/jira/browse/LUCENE-305?page=comments#action_12427015 ]

    Michael McCandless commented on LUCENE-305:
    -------------------------------------------

    See LUCENE-635 which subsumes this patch.
    [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: Lucene Developers
    Priority: Minor
    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
  • Michael McCandless (JIRA) at Aug 31, 2006 at 2:29 am
    [ http://issues.apache.org/jira/browse/LUCENE-305?page=comments#action_12431766 ]

    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: 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: Lucene Developers
    Priority: Minor
    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
  • Michael McCandless (JIRA) at Aug 31, 2006 at 2:29 am
    [ http://issues.apache.org/jira/browse/LUCENE-305?page=comments#action_12431766 ]

    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: 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: Lucene Developers
    Priority: Minor
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupjava-dev @
categorieslucene
postedAug 9, '06 at 7:42p
activeAug 31, '06 at 2:29a
posts4
users1
websitelucene.apache.org

1 user in discussion

Michael McCandless (JIRA): 4 posts

People

Translate

site design / logo © 2021 Grokbase