zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall McMullen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely
Date Tue, 17 May 2011 06:03:47 GMT

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

Marshall McMullen commented on ZOOKEEPER-965:
---------------------------------------------

Benjamin,

Thanks very much!! This was a lot of work, but also very interesting. Really glad to have
been able to jump in and work on it. As to your questions:

1) Yes, if there is an error in any of the ops in the multi-op, then the entire multi-op fails.
On the java client, this will throw an exception corresponding to the error in the op that
caused the multi-op to fail. You also optionally get an array populated with the results of
each op in the multi-op in case you want to iterate over it and see which one failed. The
semantics of the error codes in that result array are as follows

ZOK: the op would have succeeded
ZRUNTIMEINCONSISTENCY: We never tried the op because it was *after* the op that caused the
multi-op to fail. I chose this error code (somewhat arbitrarily) because it would violate
transactional consistency if we were to have committed an op inside a failing multi-op.
Anything else: The error of the failing op.

2) Ted, feel free to jump in here, but I believe the idea is to not proceed with the ops that
follow in a multi op if a version on some other node has changed out from under us. e.g. if
you have 100 ops in a multi op, and you get to the 50th one, it's a way to do a sanity check
of "hey, don't go past this point if any other client changed this node"... Does that make
sense?



> Need a multi-update command to allow multiple znodes to be updated safely
> -------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-965
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
>             Project: ZooKeeper
>          Issue Type: Bug
>    Affects Versions: 3.3.3
>            Reporter: Ted Dunning
>            Assignee: Ted Dunning
>             Fix For: 3.4.0
>
>         Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch,
ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch,
ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a list of create,
delete, update or check objects each of which has a desired version or file state in the case
of create.  If all of the version and existence constraints can be satisfied, then all updates
will be done atomically.
> Two API styles have been suggested.  One has a list as above and the other style has
a "Transaction" that allows builder-like methods to build a set of updates and a commit method
to finalize the transaction.  This can trivially be reduced to the first kind of API so the
list based API style should be considered the primitive and the builder style should be implemented
as syntactic sugar.
> The total size of all the data in all updates and creates in a single transaction should
be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.  The changes
include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form, the code
should be slightly extended to convert a list of operations to idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be detected gracefully
and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at https://github.com/tdunning/zookeeper
 and am happy to extend committer status to anyone who agrees to donate their code back to
Apache.  The final patch will be attached to this bug as normal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message