Affects Version/s: None
Fix Version/s: None
Having an immutable DataTree structure in the ZooKeeper server is an ambitious goal but is possible. Advantages would be:
- No synchronization needed when accessing the DataTree.
- The snapshotter thread gets an immutable datatree and will write a consistent DataTree to the disk.
- No headaches whether multi transactions could lead to issues with (de)serialization.
- Much better testability.
- No concurrency - No headaches.
- I hope for considerable speed improvements. Maybe also some memory savings, at least from refactorings possible after this step.
- Statistical Data about the tree can be updated on every tree modification and is always consistent. The need to save statistical data in extra nodes for the quota feature goes away.
Possible further improvements:
Read requests actually don't need to enter the processor pipeline. Instead each server connection could get a reference to a (zxid, tree) tuple. Updates
are delivered as (zxid, newTree, triggerWatchesCallback) to the server connections.
The watches could be managed at each server connection instead of centrally at the DataTree.
|DataTree deserialization methods should return DataTree instance||Open||Unassigned|