[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975732#action_12975732
]
Ted Dunning commented on ZOOKEEPER-965:
---------------------------------------
Henry,
I can definitely set up some sub-tasks.
Relative to the iterable and polymorphism, I don't much see the problem. In
particular, I think I set it up so that the API visible components are
independent of the lower levels.
In C, for instance, using a list/array/whatever of structs with a type field
and a super set of all possible fields would work out just about as easily as
the Java version. The jute objects don't overlap and both Java and C api's
would have to be creating and serializing the jute objects. When jute gets the
boot, I would presume that we would have something similar in terms of a
separation between the API level structures and the serialization level
structures. In particular, I simply re-used most of the request structures in
the multi request and only added the single check structure (and the multi for
the overall header).
So I really don't see the problem on the C side of things. To be concrete, I
see that the C side could have something kind of like:
result multi(op[] ops) // assumes last op is null
or
result multi(op[] ops, int opCount)
where
{verbatim}
typedef struct {
int type; // always present
char *path; // always present
uint8 * data; // only with create, setData
ACL* acl; // only for create
int version; // only for delete, setData
}
{verbatim}
Doesn't this match up well enough with the Java side of the house? I would be
loathe to lose the idiomatic Java idiom.
> 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.
-
You can reply to this email to add a comment to the issue online.
