[ 
https://issues.apache.org/jira/browse/CURATOR-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mohamed Mohsen updated CURATOR-592:
-----------------------------------
    Description: 
{{InterProcessMutex}} performs two significant steps to 
[acquire|https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/locks/InterProcessMutex.html#acquire()]
 its lock:
 # Creates an ephemeral sequential node. This practically means that it took a 
position in the lock queue (i.e. based on its sequence value).
 # Blocks until the lock is acquired.

This improvement is about providing a callback that notifies the caller that 
the lock order is reserved.

The use for this, at least for us, is that we needed to differentiate between 
the two phases for higher concurrency because we can do other actions after 
knowing that theĀ {{InterProcessMutex}} order is known. Especially since the 
lock acquisition can take too long, depending on the situation of course.

  was:
InterProcessMutex performs two significant steps to 
[acquire|https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/locks/InterProcessMutex.html#acquire()]
 its lock:
 # Creates an ephemeral sequential node. This practically means that it took a 
position in the lock queue (i.e. based on its sequence value).
 # Blocks until the lock is acquired.

This improvement is about providing a callback that notifies the caller that 
the lock order is reserved.

The use for this, at least for us, is that we needed to differentiate between 
the two phases for higher concurrency because we can do other actions after 
knowing that the InterProcessMutex order is known. Especially since the lock 
acquisition can take too long, depending on the situation of course.


> Provide a callback that is fired after the InterProcessMutex creates its 
> ephemeral node
> ---------------------------------------------------------------------------------------
>
>                 Key: CURATOR-592
>                 URL: https://issues.apache.org/jira/browse/CURATOR-592
>             Project: Apache Curator
>          Issue Type: Improvement
>          Components: Recipes
>    Affects Versions: 5.1.0
>            Reporter: Mohamed Mohsen
>            Priority: Major
>              Labels: Concurrency
>             Fix For: TBD
>
>
> {{InterProcessMutex}} performs two significant steps to 
> [acquire|https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/locks/InterProcessMutex.html#acquire()]
>  its lock:
>  # Creates an ephemeral sequential node. This practically means that it took 
> a position in the lock queue (i.e. based on its sequence value).
>  # Blocks until the lock is acquired.
> This improvement is about providing a callback that notifies the caller that 
> the lock order is reserved.
> The use for this, at least for us, is that we needed to differentiate between 
> the two phases for higher concurrency because we can do other actions after 
> knowing that theĀ {{InterProcessMutex}} order is known. Especially since the 
> lock acquisition can take too long, depending on the situation of course.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to