Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
Date: Mon, 2 May 2011 07:30:03 +0000 (UTC)
From: "Marshall McMullen (JIRA)" <jira@apache.org>
To: dev@zookeeper.apache.org
Message-ID: 
 <403780000.14751.1304321403260.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <618906.38111293495645173.JavaMail.jira@thor>
Subject: [jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to
 allow multiple znodes to be updated safely
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

I've committed an initial pass at the necessary work in the C client. I did some refactoring to avoid some massive code duplication as well. Notes from my checkin comments:


 This adds new zoo_multi and zoo_amulti interfaces to the C client to
    atomically commit (either synchronously or asynchronously) a set of
    operations. The server side guarantees transactional consistency
    in that *all* the ops either fail or succeed.
    
    Limitations of this implementation:
    - asynchronous interface (zoo_amulti) doesn't work yet.
    
    - can't get back the index of the failing op from zoo_multi though
      zoo_amulti is designed to support this. I have a plan for how
      to implement this in zoo_multi too.
    
    - Only limited testing done on C client. The one test I did write
      only works in multithread mode. Looks to be a limitation of the
      test case I modelled mine after.
    
    Cleanup/refactoring needed:
    - Deal with deeply nested errors in zoo_amulti better (free any
      allocated memory, etc).
    
    - Don't need the existing ErrorResponse (added on java side to
      allow determining which op failed). On C side it was so much
      easier to just add a field to MultiHeader to indicate if that
      op failed or not. That will make the Java side a lot cleaner


> 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
>            Reporter: Ted Dunning
>            Assignee: Ted Dunning
>             Fix For: 3.4.0
>
>
> 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