I just put down a call for 4PM PDT on Friday 4/14 to discuss the multi-op transaction extension for Zookeeper.
Please contact me off-list ([email protected]) to let me know if you are interested in participating. It the number is small, I would like to use my skype address as the rendezvous (tdunning.veoh). If the number gets too large for skype voice, I may opt for another option, but I would to let people talk as opposed to just typing. Please do RSVP so I can react in advance if we need an alternative mechanism. On Thu, Apr 14, 2011 at 9:59 AM, Marshall McMullen (JIRA) <[email protected]>wrote: > > [ > https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019909#comment-13019909] > > Marshall McMullen commented on ZOOKEEPER-965: > --------------------------------------------- > > By the way, I'm in Colorado (time zone is Mountain) in case that affects > when you'd like to schedule the call. I'm happy to do it whenever it's > convenient for you though. > > > 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 >
