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. On Wed, Oct 24, 2012 at 10:44 AM, Jimmy Xiang (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/ZOOKEEPER-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483372#comment-13483372] > > Jimmy Xiang commented on ZOOKEEPER-1568: > ---------------------------------------- > > Yes, that's what we are using now. It is working fine. I was thinking if > there is still room for improvement. > > > 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 >
