hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Kellerman (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (HADOOP-2348) [hbase] lock_id in HTable.startUpdate and commit/abort is misleading and useless
Date Wed, 05 Dec 2007 00:14:43 GMT

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

Jim Kellerman reassigned HADOOP-2348:
-------------------------------------

    Assignee: Jim Kellerman

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


Mime
View raw message