[
https://issues.apache.org/jira/browse/CURATOR-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cam McKenzie updated CURATOR-542:
---------------------------------
Fix Version/s: (was: 4.3.0)
TBD
> Add recipe to help with leader-based transactions
> -------------------------------------------------
>
> Key: CURATOR-542
> URL: https://issues.apache.org/jira/browse/CURATOR-542
> Project: Apache Curator
> Issue Type: New Feature
> Components: Recipes
> Affects Versions: 4.2.0
> Reporter: Jordan Zimmerman
> Priority: Major
> Fix For: TBD
>
>
> See discussion here:
> http://mail-archives.apache.org/mod_mbox/curator-user/201909.mbox/%3ccall9tylwpz-otqufznlqcpxi2cbo3fd_mrlgf+rka5puwak...@mail.gmail.com%3e
> Given the issues regarding GC pauses, etc.
> (https://cwiki.apache.org/confluence/display/CURATOR/TN10) there is no 100%
> guarantee that a instance using one of the leader election, lock, etc.
> recipes that they actually are they current leader (or lock owner). This has
> implications for any actions taken where leadership is assumed. For
> operations on ZooKeeper this can be improved by using a versioned
> coordination node.
> Add a new recipe that complements leader selection, locking to manage a
> coordination node. When a client is elected leader (or owns a lock, etc.) and
> needs to perform a ZooKeeper operation it can ensure that it is the true
> leader by including the version number of the coordination node in a
> ZooKeeper transaction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
