You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2007/12/04 23:42:43 UTC
[jira] Created: (HADOOP-2348) [hbase] lock_id in HTable.startUpdate
and commit/abort is misleading and useless
[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.
[jira] Commented: (HADOOP-2348) [hbase] lock_id in
HTable.startUpdate and commit/abort is misleading and useless
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548476 ]
Bryan Duxbury commented on HADOOP-2348:
---------------------------------------
If we actually want to have the ability to have multiple updates in progress at once, why don't we expose the BatchUpdate object, or better, create some sort of Bigtable-esque RowMutation class that the users can create and then apply to a table? It'd be nicer and more object-oriented than simply methods hanging off of HTable and grouped by a random number.
> [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.
[jira] Commented: (HADOOP-2348) [hbase] lock_id in
HTable.startUpdate and commit/abort is misleading and useless
Posted by "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.
[jira] Resolved: (HADOOP-2348) [hbase] lock_id in
HTable.startUpdate and commit/abort is misleading and useless
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Kellerman resolved HADOOP-2348.
-----------------------------------
Resolution: Won't Fix
> [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
> Components: contrib/hbase
> 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.
[jira] Commented: (HADOOP-2348) [hbase] lock_id in
HTable.startUpdate and commit/abort is misleading and useless
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548497 ]
Bryan Duxbury commented on HADOOP-2348:
---------------------------------------
If BatchUpdate has to be a certain way to maintain the wire protocol,
that seems to me to be a respectable reason to make that class
private and make a new public class that can be transformed into a
BatchUpdate properly behind the scenes. The existing mutation methods
could then be changed under the hood if we're determined to maintain
the existing interface.
> [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.
[jira] Commented: (HADOOP-2348) [hbase] lock_id in
HTable.startUpdate and commit/abort is misleading and useless
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (HADOOP-2348) [hbase] lock_id in HTable.startUpdate
and commit/abort is misleading and useless
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated HADOOP-2348:
----------------------------------
Component/s: contrib/hbase
> [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
> Components: contrib/hbase
> 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.
[jira] Assigned: (HADOOP-2348) [hbase] lock_id in
HTable.startUpdate and commit/abort is misleading and useless
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ 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.