[CURATOR-542] Add recipe to help with leader-based transactions

• Type: New Feature
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 4.2.0
• Fix Version/s: TBD
• Component/s: Recipes
• Assignee: Unassigned
• Reporter: Jordan Zimmerman
• Created: 21/Sep/19 19:35
• Updated: 19/Aug/24 08:17

Description

See discussion here: http://mail-archives.apache.org/mod_mbox/curator-user/201909.mbox/[e-mail]%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.

Issue Links

• is related to: CURATOR-604 Double locking issue while using InterProcessMutex lock code