You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Cam McKenzie (Jira)" <ji...@apache.org> on 2020/02/29 08:50:00 UTC

[jira] [Updated] (CURATOR-542) Add recipe to help with leader-based transactions

     [ 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+RKa5pUWAK6oA@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)