[
https://issues.apache.org/jira/browse/ZOOKEEPER-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048197#comment-13048197
]
Benjamin Reed commented on ZOOKEEPER-1092:
------------------------------------------
in reviewing some of the patches lately, i was again bothered by the complexity
of outstandingChanges used by PrepRP and FinalRP. Both threads touch that list
and prepRP checks both the list and the datatree.
right now datatree has the committed changes, but if we make datatree store the
pending changes, then it can be completely maintained by the prepRP. it would
also mean that prepRP would execute all operations: both the read and write
operations. it turns out that we never take advantage of the fact that datatree
contains only committed operations.
in general, i think this would simplify the code, make finalRP go away, allow
us to get rid of outstandingChanges and allow us to do all datatree
manipulation in the prepRP.
there is a downside: currently order operations as we get them from the
clients, which works with the above. we have occasionally talked about letting
read operations short circuit the pipeline if there are no writes from the
client issuing the read in the pipeline. short circuited requests would go
straight to finalRP. if we implement the above, this optimization would be much
harder to implement. (i don't see it as much of an issue since we don't have
any plans to implement it currently.)
> get rid of pending changes
> --------------------------
>
> Key: ZOOKEEPER-1092
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1092
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Benjamin Reed
> Priority: Minor
>
> pending changes used by PrepRequestProcessor and FinalRequestProcessor is
> complicated and requires synchronization between threads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
