[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025157#comment-13025157
]
Marshall McMullen commented on ZOOKEEPER-965:
---------------------------------------------
Thanks everyone for all the help and the kind words. Hopefully when I get this
all committed I've done most of it correctly :-).
I'm going to go ahead and commit my pending changes to Ted's private git
branch. It's not perfect as there are a few things I wanted to work out better
but it wasn't working out as well as I'd have liked. Specifically:
1. No client work is done. I'm not sure where to start on this, so if someone
wants to point me the right direction I'll tackle that next.
2. PrepRequestProcessor.java:432: I don't like how I had to serialize the
individual Txns into the MultiTxn only to deserialize it in the next request
processor in DataTree. I wanted to just have MultiTxn contain a list of Txns.
However, the jute auto code generation stuff got in my way. I couldn't figure
out how to make the MultiTxn contain a list of Txns so I made it a buffer that
I serialize into/out of. It works, but I think this could be better.
3. Several places where we do a switch on types of ops inside multi op, and in
default it throws an IOException. That
doesn't seem very appropriate. Maybe instead a KeeperException.APIERROR or
perhaps we need a (new) specific exception?
4. There is currently no way to tell which op in a multi op failed. It's
implemented so that it throws the KeeperException corresponding to the first op
in the multi op that caused the multi op to pass. However, it might be more
useful if there was a way to know exactly which op failed. I tried several
approaches to implement this but couldn't get it working correctly. Maybe
someone can offer some advice on this.
I'll commit my pending changes momentarily.
> 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
