[
https://issues.apache.org/jira/browse/CURATOR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100630#comment-14100630
]
ASF GitHub Bot commented on CURATOR-84:
---------------------------------------
Github user karkum commented on a diff in the pull request:
https://github.com/apache/curator/pull/38#discussion_r16353602
--- Diff:
curator-recipes/src/main/java/org/apache/curator/framework/recipes/locks/InterProcessMutex.java
---
@@ -61,7 +61,17 @@ private LockData(Thread owningThread, String lockPath)
*/
public InterProcessMutex(CuratorFramework client, String path)
{
- this(client, path, LOCK_NAME, 1, new
StandardLockInternalsDriver());
+ this(client, path, new StandardLockInternalsDriver());
+ }
+
+ /**
+ * @param client client
+ * @param path the path to lock
+ * @param driver lock driver
+ */
+ private InterProcessMutex(CuratorFramework client, String path,
LockInternalsDriver driver)
--- End diff --
Yes, I was just about to comment back. The plan was for a client using the
```InterProcessMutex``` to specify their own ```LockInternalsDriver``` with
different parameters than the one provided by the default
```StandardLockInternalsDriver```. We definitely need this to be public.
I'm not sure what you mean by "Also LockInternalsDriver would need to be
public?". Could you please elaborate?
> 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)
