[
https://issues.apache.org/jira/browse/ZOOKEEPER-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486471#comment-13486471
]
Flavio Junqueira commented on ZOOKEEPER-1568:
---------------------------------------------
Hi guys, Here are two concerns I have:
# With this proposal we are now mixing performance and correctness (atomicity)
in the multi abstraction. At this point, I'd rather stick only to the
correctness aspect.
# The architecture of zookeeper is essentially an execution pipeline, which has
been optimized to provide both low latency and high throughput. This proposal
goes in the opposite the direction and tries to promote the execution of large
batches instead of individual operations at least for some use cases.
In general, if it there is an opportunity to improve the performance of the
system, then we should pursue it, but at this point it is not even clear how
much difference it would actually make if any. Can we actually make sure that
such an app-level batching makes a significant difference compared to trunk
with respect to performance? And if it does, what exactly is the culprit? Can
we fix it without introducing a new API feature?
The point about getChildren capturing fewer events sounds like a "good to have"
but not really "must have", but please correct me if I'm wrong.
> multi should have a non-transaction version
> -------------------------------------------
>
> Key: ZOOKEEPER-1568
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1568
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Jimmy Xiang
>
> Currently multi is transactional, i.e. all or none. However, sometimes, we
> don't want that. We want all operations to be executed. Even some
> operation(s) fails, it is ok. We just need to know the result of each
> operation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
