Zookeeper, Data Versioning

Question

Here is the scenario:

1. Znode created: create /config 12345 (For example created on 12/12/12)
2. Update is made to this configuration, set /config 34567 (For example modified on 12/12/13)
3. After a month the configuration is modified again, set /config 567889 (For example modified on 1/1/13)

Question:

1. What is the best way to 'get'(or maintain) the version history associated with '/config', i.e. is there a way I could get the entire history of data stored in the node?
2. What is the best way for me to revert my current configuration value i.e. 567889, to the original value of 12345? (By crawling up the data history of the node)

I need some help in figuring this out. Thank you

Answer 1

I don't think there is an easy way to do this. Here is how I would achieve this:

 1. divide the configurations in two znodes [say, /Config and /Config/data-*]
  - /config/data-* are the data nodes which will store the configuration
  - /config will store the history of all the configs so far
 2. /Config/data-* is sequential node
       So, every znode will have a strictly increasing number appended to it.
       For example, /config/data-1, /config/data-2, and so on. Your configuration object
       will be stored in data nodes.
         /config/data-1 -> 12345
         /config/data-2 -> 34567
         /config/data-3 -> 56789
 3. /config will look like this: 
    ["/config/data-1","/config/data-2","/config/data-3"] or just 
    ["1", "2", "3"]

Here is the write algorithm:

 1. create a data node with new config. Which will return the the actual path.
    say /config/data-4
 2. now try to do conditional update on /config with "/config/data-4" or just "4" appended to
    the existing data i.e. 
    ["/config/data-1","/config/data-2","/config/data-3","/config/data-4"] or just
    ["1", "2", "3","4"]
    - if update succeeds, end.
    - else, someone else was simultaneously trying to update the config and won the race.
     So, either quit or try again starting with step1.

NOTE: if update fails, you will have effectively orphan nodes in the tree, which can be cleaned up on regular basis in automated way

Read will be:

1. call sync [if consistency is important]
2. read /config
3. pick the path which is at the last index in the array retrieved from /config
4. read the config from that path

To rollback, either delete the last entry from the list stored in /config or append last but second entry of the list to the end