[
https://issues.apache.org/jira/browse/ZOOKEEPER-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483590#comment-13483590
]
Marshall McMullen commented on ZOOKEEPER-1568:
----------------------------------------------
I actually think there is a valid use case for this. Mostly for performance
reasons. Because a multi is one transaction, it causes less permuation on the
distributed and replicated state of zookeeper than multiple individual
operations not in a multi.
With a Multi:
- You only pay the cost of the RPC overhead once rather than on each individual
operation
- You get one flush of the leader channel rather than multiple ones for each
write operation
- A multi will case one new snapshot/log to be generated rather than multiple
ones for each operation
There are other reasons that make this a good reason too that are not
performance based. e.g., if it makes the programmer's job easier to use a multi
with these semantics, then that's a win.
In other distributed databases I've worked on, we used different terminology to
disinguish between a multi op that all succeed/fail vs one that does not. We
used the term "Batch" to imply we were batching up operations but there was no
guarantee they'd all succeed/fail.
> 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
