[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022833#comment-13022833
]
Marshall McMullen commented on ZOOKEEPER-965:
---------------------------------------------
I've been having email discussions with various folks that have been super
helpful in getting this implemented. I'm going to try to summaries some of the
key points here for posterity and other interested parties.
Ted's initial version of this adds a new MultiTransactionRecord with an OpCode
of 'multi'. This contains a list of all the ops that need to get committed. The
design is such that all of the ops must succeed in order for the multi op to
succeed. If any one of the ops fails, then the entire multi op must fail.
The basic approach I've taken to enhance Ted's version is to look at all the
processors and enhance them as needed in order to support the new multi op.
Here's the flow of the processors (as documented in LeaderZooKeeperServer.java):
processors: PrepRequestProcessor -> ProposalRequestProcessor ->
* CommitProcessor -> Leader.ToBeAppliedRequestProcessor ->
* FinalRequestProcessor
The purpose of PrepRequestProcessor (pRequest) is essentially to validate the
incoming request and ensure (for example) the path we want to create doesn't
already exist, or the path we want to delete does exist. So I've enhanced
PrepRequestProcessor and added a case statement for 'multi' that essentially
iterates over all the ops contained in the multi op and calls pRequest on each.
If any of them fails, then it fails. Otherwise, a new MultiTxn will be created.
This is **one** transaction that contains all the ops in the multi op.
> 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
