[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975601#action_12975601
]
Thomas Koch commented on ZOOKEEPER-965:
---------------------------------------
Please Ted, don't move that fast. I've three outstanding issues that needs
review or comments from commiters and that could influence your patch. Your
current patch directly conflicts with ZOOKEEPER-911 and how I'd propose to
implement it. I'm waiting on a comment for ZOOKEEPER-849 (on the mailing list)
to continue with that. And once ZOOKEEPER-837 would be committed I could
continue with ZOOKEEPER-911.
I'm also working hard to clean up the mess that ZooKeeper currently still is
and would ask you not to make it worse with your patch.
Things are moving extremely slow here at ZooKeeper because commiters don't have
time for reviews or comments. I'm working since may (more then six months now)
to slowly move the ZooKeeper API in a usable state.
I gave a presentation about the internals of ZooKeeper in my team before
christmas. People were pretty much scared at the poor code quality of such a
central peace of some NoSQL systems.
Could you also be so kind please and provide a use case for your request? The
issue of transactions has been raised multiple times on the mailing list and
one standard answer was to rather use one ZNode that'd contain all necessary
informations. Maybe there's an easier solution to what you intend to do?
Hope I don't sound too rude. I feel a little frustrated. :-)
> 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
> 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.
