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

[email protected] commented on ZOOKEEPER-965:
---------------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/739/#review750
-----------------------------------------------------------


this looks really great! one thing to think about (you don't need to think 
about it too long, but it would be great if you could "fix it"): we generally 
only use generated jute Record instances. i think this makes it easier if we 
ever switch serialization libraries, but MultiResponse is not generated. i 
understand why, but it would be cool if we could use a generated class. this is 
not blocking the patch.

the cleanup of pending ops was not in the uploaded diffs, but i looked at the 
code on git hub. i think this is almost right, but removeChangeRecord has a 
bug: we do the checking based on the Map not the list, so when we remove the 
ChangeRecord we need to check to see if there was something there before that 
we replaced and put it back. i think this is the last blocker that i can see.

- Benjamin


On 2011-05-29 23:54:13, Ted Dunning wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/739/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2011-05-29 23:54:13)
bq.  
bq.  
bq.  Review request for zookeeper and Benjamin Reed.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  This mega-patch adds the multi-op capability to ZK.  This allows a batch 
of create, delete, update or version-check operations to 
bq.  succeed or fail together.   Both C and java bindings are provided.
bq.  
bq.  
bq.  This addresses bug ZOOKEEPER-965.
bq.      https://issues.apache.org/jira/browse/ZOOKEEPER-965
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    src/c/Makefile.am 65830fe 
bq.    src/c/include/proto.h 843032f 
bq.    src/c/include/zookeeper.h c055edb 
bq.    src/c/src/zookeeper.c db715b0 
bq.    src/c/tests/TestMulti.cc PRE-CREATION 
bq.    src/c/tests/TestOperations.cc f9441ea 
bq.    src/c/tests/ZKMocks.cc a75dce6 
bq.    src/java/main/org/apache/zookeeper/MultiResponse.java PRE-CREATION 
bq.    src/java/main/org/apache/zookeeper/MultiTransactionRecord.java 
PRE-CREATION 
bq.    src/java/main/org/apache/zookeeper/Op.java PRE-CREATION 
bq.    src/java/main/org/apache/zookeeper/OpResult.java PRE-CREATION 
bq.    src/java/main/org/apache/zookeeper/Transaction.java PRE-CREATION 
bq.    src/java/main/org/apache/zookeeper/ZooDefs.java 832976f 
bq.    src/java/main/org/apache/zookeeper/ZooKeeper.java 00b4012 
bq.    src/java/main/org/apache/zookeeper/server/DataTree.java d16537e 
bq.    src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java 
2538cf7 
bq.    src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 
50f208d 
bq.    src/java/main/org/apache/zookeeper/server/Request.java a5c57e2 
bq.    src/java/main/org/apache/zookeeper/server/RequestProcessor.java 5c3e8ff 
bq.    src/java/main/org/apache/zookeeper/server/TraceFormatter.java 8ece929 
bq.    src/java/main/org/apache/zookeeper/server/package.html 3ec7656 
bq.    src/java/main/org/apache/zookeeper/server/quorum/CommitProcessor.java 
49affd5 
bq.    src/java/main/org/apache/zookeeper/server/util/SerializeUtils.java 
0ad4dd6 
bq.    src/java/test/org/apache/zookeeper/MultiResponseTest.java PRE-CREATION 
bq.    src/java/test/org/apache/zookeeper/MultiTransactionRecordTest.java 
PRE-CREATION 
bq.    src/java/test/org/apache/zookeeper/test/MultiTransactionTest.java 
PRE-CREATION 
bq.    src/zookeeper.jute 7d96f32 
bq.  
bq.  Diff: https://reviews.apache.org/r/739/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  A number of unit tests have been implemented.  Test coverage is very good.
bq.  
bq.  A sample application has been written to do simple operations on a graph 
of nodes.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Ted
bq.  
bq.



> 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, 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

Reply via email to