[
https://issues.apache.org/jira/browse/CURATOR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100638#comment-14100638
]
ASF GitHub Bot commented on CURATOR-84:
---------------------------------------
Github user Randgalt commented on a diff in the pull request:
https://github.com/apache/curator/pull/38#discussion_r16354016
--- 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 --
If you make StandardLockInternalsDriver public, LockInternalsDriver should
also be public. LockInternalsDriver is the actual interface.
StandardLockInternalsDriver is just one implementation of it.
> 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)
