You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Thomas Koch (Commented) (JIRA)" <ji...@apache.org> on 2011/11/04 17:25:51 UTC

[jira] [Commented] (ZOOKEEPER-1285) make DataTree immutable

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144125#comment-13144125 ] 

Thomas Koch commented on ZOOKEEPER-1285:
----------------------------------------

To explain it more detailed: The nodes HashMap of the DataTree would go away and instead each DataNode has a HashMap of <String, DataNode>. The DataTree class holds a reference to the root node and accesses all sub nodes by traversing the nodes. DataNodes are immutable. Each change to a DataNode including additions, removals or replacements of child nodes require the instantiation of a new DataNode instance.
                
> 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