curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CURATOR-84) More flexibility for InterProcessMutex extensions
Date Tue, 19 Aug 2014 07:10:18 GMT


ASF GitHub Bot commented on CURATOR-84:

Github user jojovilco commented on the pull request:
    Yes, you are correct. 
    Indeed in default lock implementation it can be done by watching connection. But not in
other custom lock implementations which this issue aims to target. I would make access to
lockPath protected, to be managed by lock implementation itself. Public access can mislead
the purpose. E.g. is it ok to directly delete the path to release the lock? No! There is different
API for that.
    For me, it is more intuitive to reason about lost lock from watching the actual lockPath
node, than derive its existence from lost connection. But this is, off course, subjective.

> More flexibility for InterProcessMutex extensions
> -------------------------------------------------
>                 Key: CURATOR-84
>                 URL:
>             Project: Apache Curator
>          Issue Type: Wish
>          Components: Recipes
>    Affects Versions: 2.3.0
>            Reporter: Jozef Vilcek
>         Attachments: CURATOR-84.patch
> I have a need for a durable InterProcessMutex. Main reason for this are processes with
critical sections, where I can not afford to loose a lock due to session expiration. In such
case, others might acquire a lock and kick in while the previous process is still running
but e.g. experiencing connection issues. To kill this temporally detached process in favor
of others would be too costly.
> To achieve such behavior, I need lock nodes to be created in PERSISTENT mode. This is
not possible to do easily with currently implementation of locks due to few internal scoped
classes and methods. I would like to change this.

This message was sent by Atlassian JIRA

View raw message