How to implement 2pc in Zookeeper cluster?

2
votes

I have a question regarding implementation two-phase-commit protocol in zookeeper cluster to coordinate certain transaction among multiple client connections. Right now I have the following idea:

  • Coordinator C register transaction node /app/tx
  • register processing node for each involved party /app/tx/%d (Ni)
  • set watchers on each involved party node Ni
  • notify each Ni about new transaction tx
  • Ni checks that its node is created
  • Ni sets transaction to prepare()/abort()
  • C recieves the result from all the parties and decides abort/continue
  • if continue, each Ni executes query
  • Ni notifies C with ok/fail
  • C decides abort|commit
  • C notifies everybody about the result.
  • tx is commited

But I am not sure is it a right direction ? And I am not sure how to implement this in python kazoo or any other language (Java)? It would be nice if you can help me by providing snippet or correcting my algorithm ? In addition, how to extend this protocol for inter-zookeeper communication? Say, we maintain multiple different zookeeper clusters that are wrapped into zones or any other abstract entity and we would like to perform such explicit transactions on particular zone using two-phase commit ?

1
javapythonapache-zookeeperdistributed-transactions2phase-commit
It looks like you might have taken the standard recipe, zookeeper.apache.org/doc/trunk/…, and added more complexity (more stuff for C to do). I think that the nodes can decide for themselves if the transaction should be committed or not, since they are watching all ZK locations – Christopher Swenson

1 Answers

0
votes

An important tweak to your algorithm based on 2PC using Zkis,

  • Coordinator C register transaction node /app/tx
  • Coordinator notify clients about transaction
  • Coordinator sets WATCH on the /app/tx when nodes are created under it
  • Each client creates an ephimeral node /app/tx/node_i with decision on prepare/abort
  • Client sets a watch on the node
  • Coorindator decides to commit / abort after waiting for timeout or all nodes created
  • Coordinator changes the value of ephimeral nodes for each client to commit / abort
  • Clients commit / abort the transaction
  • Clients update the node value to acknowledged