[
https://issues.apache.org/jira/browse/HADOOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548486
]
Jim Kellerman commented on HADOOP-2348:
---------------------------------------
Actually BatchUpdate is a public class right now, but we'd have to make some
changes to it and HTable to implement your suggestion. The changes to
BatchUpdate would have to be such that it doesn't break the current HTable to
region server wire protocol, but it is doable.
Adding a new class would mean changing the wire protocol which would require an
incompatible change.
> [hbase] lock_id in HTable.startUpdate and commit/abort is misleading and
> useless
> --------------------------------------------------------------------------------
>
> Key: HADOOP-2348
> URL: https://issues.apache.org/jira/browse/HADOOP-2348
> Project: Hadoop
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Assignee: Jim Kellerman
> Priority: Minor
>
> In the past, the lock id returned by HTable.startUpdate was a real lock id
> from a remote server. However, that has been superceeded by the BatchUpdate
> process, so now the lock id is just an arbitrary value. More, it doesn't
> actually add any value, because while it implies that you could start two
> updates on the same HTable and commit them separately, this is in fact not
> the case. Any attempt to do a second startUpdate throws an
> IllegalStateException.
> Since there is no added functionality afforded by the presence of this
> parameter, I suggest that we overload all methods that use it to ignore it
> and print a deprecation notice. startUpdate can just return a constant like 1
> and eventually turn into a boolean or some other useful value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
