Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
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.
Attachments
Issue Links
- depends upon
-
ZOOKEEPER-1228 Cleanup SessionTracker
- Open
-
ZOOKEEPER-1230 Cleanup FileTxnLog
- Open
-
ZOOKEEPER-1259 central mapping from type to txn record class
- Open
-
ZOOKEEPER-1255 unused fields in DataTree.ProcessTxnResult
- Open
-
ZOOKEEPER-1276 ZKDatabase should not hold reference to FileTxnSnapLog
- Open
-
ZOOKEEPER-1279 Only SessionTracker should hold reference to sessionsWithTimeouts
- Open
-
ZOOKEEPER-1253 return value of DataTree.createNode is never used
- Resolved
-
ZOOKEEPER-1258 Move MultiResponse creation out of FinalRequestProcessor
- Patch Available
- supercedes
-
ZOOKEEPER-1092 get rid of pending changes
- Open
1.
|
DataTree deserialization methods should return DataTree instance | Open | Unassigned |