[
https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253997#comment-13253997
]
Jesse Yates commented on HBASE-5790:
------------------------------------
bq. I don't see how version is used to filter child nodes in the above method.
It works because of the line:
{code}
trans.delete(path, version);
{code}
in addAllChildrenToDeleteTransaction - only children with the same version will
be deleted. Generally, we are just going to want to delete all versions
(version == -1), so don't often expect funky cases, but this way also ensures
that you just delete children with the same version as the parent (and fail if
those versions don't match up). I didn't want to go with any assumptions on
versions of children vs. parent since there was not need for it yet AFAIK.
bq. Will there be any request size problem if the subtree to delete is large?
Not unless you are going to blow out the stack or memory. However, that seems
incredibly unlikely. Seems a little excessive at this point to do the tail
recursion optimization, but can switch to that if it seems a big issue.
> ZKUtil deleteRecurisively should be a recoverable operation
> -----------------------------------------------------------
>
> Key: HBASE-5790
> URL: https://issues.apache.org/jira/browse/HBASE-5790
> Project: HBase
> Issue Type: Improvement
> Reporter: Jesse Yates
> Assignee: Jesse Yates
> Labels: zookeeper
> Fix For: 0.96.0, 0.94.1
>
> Attachments: java_HBASE-5790.patch
>
>
> As of 3.4.3 Zookeeper now has full, multi-operation transaction. This means
> we can wholesale delete chunks of the zk tree and ensure that we don't have
> any pesky recursive delete issues where we delete the children of a node, but
> then a child joins before deletion of the parent. Even without transactions,
> this should be the behavior, but it is possible to make it much cleaner now
> that we have this new feature in zk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
