[jira] Commented: (HADOOP-2348) [hbase] lock_id in HTable.startUpdate and commit/abort is misleading and useless

["Jim Kellerman (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548474 ] 

Jim Kellerman commented on HADOOP-2348:
---------------------------------------

Absolutely correct.

While HTable is thread safe it is not multi-update friendly.

What I would propose doing is allowing multiple concurrent updates and that the lockid be the identifier for a particular update.

> [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
>            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.