[
https://issues.apache.org/jira/browse/CURATOR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101954#comment-14101954
]
ASF GitHub Bot commented on CURATOR-84:
---------------------------------------
Github user jojovilco commented on the pull request:
https://github.com/apache/curator/pull/38#issuecomment-52597742
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: https://issues.apache.org/jira/browse/CURATOR-84
> 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
(v6.2#6252)
