[
https://issues.apache.org/jira/browse/ZOOKEEPER-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Koch updated ZOOKEEPER-1285:
-----------------------------------
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.
was:
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.
> make DataTree immutable
> -----------------------
>
> Key: ZOOKEEPER-1285
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1285
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Thomas Koch
> Assignee: Thomas Koch
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
