[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025624#comment-13025624
]
Marshall McMullen commented on ZOOKEEPER-965:
---------------------------------------------
I've committed my work from the last couple of days that implements a mechanism
to detect which op in the multi op failed. From my commit message:
Enhanced multi-op so caller can tell which op failed.
This turned out to be a lot harder than it looked. The jist of
the problem was I was throwing an exception early in
PrepRequestProcessor on the first error in the multi op. That was
the right thing to do, but it didn't allow returning the results
back to the caller as the exception caused us to discard the current
multi-op and create a new ErrorTxn that traversed all the other
request handlers.
Instead, this new implementation retains the multi-op all the way
through all the request handlers (though it becomes a MultiTxn
and ultimately a MultiResponse). It now allows returning back
to the caller the result for each individual Op.
In ZooKeeper's multi function, it still ultimately behaves the
same as before -- namely the first error in the results array
gets detected as the fatal error that caused the multi op to fail
and this is what we throw as our exception.
The major difference is that we first (optionally) populate a given
result array *before* we throw the exception.
There are some rough details here still and some things I'd like to
fix. But it works really well and all the major bugs are flushed
out so I'm committing....
> 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
