Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 43623 invoked from network); 5 Dec 2007 00:15:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Dec 2007 00:15:10 -0000 Received: (qmail 60799 invoked by uid 500); 5 Dec 2007 00:14:53 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 60760 invoked by uid 500); 5 Dec 2007 00:14:53 -0000 Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hadoop-dev@lucene.apache.org Delivered-To: mailing list hadoop-dev@lucene.apache.org Received: (qmail 60457 invoked by uid 99); 5 Dec 2007 00:14:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2007 16:14:52 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Dec 2007 00:14:40 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 69D8971423E for ; Tue, 4 Dec 2007 16:14:43 -0800 (PST) Message-ID: <20305508.1196813683430.JavaMail.jira@brutus> Date: Tue, 4 Dec 2007 16:14:43 -0800 (PST) From: "Jim Kellerman (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Assigned: (HADOOP-2348) [hbase] lock_id in HTable.startUpdate and commit/abort is misleading and useless In-Reply-To: <11758958.1196808163266.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on 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.