Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <7517228.307111294813908952.JavaMail.jira@thor>
Date: Wed, 12 Jan 2011 01:31:48 -0500 (EST)
From: "dhruba borthakur (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Subject: [jira] Commented: (HBASE-3434) ability to increment a counter
 without reading original value from storage
In-Reply-To: <23338946.251001294655025389.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980585#action_12980585 ] 

dhruba borthakur commented on HBASE-3434:
-----------------------------------------

Using co-processors seems to be the right thing to do. if I build it this way, do I still contribute the code back to the Apache HBase svn tree? if so, where will it be located?

> ability to increment a counter without reading original value from storage
> --------------------------------------------------------------------------
>
>                 Key: HBASE-3434
>                 URL: https://issues.apache.org/jira/browse/HBASE-3434
>             Project: HBase
>          Issue Type: Improvement
>          Components: client, regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> There are a bunch of applications that do read-modify-write operations on HBase constructs, e.g  a counter; The counter value has to be read in from hdfs before it can be incremented.  We have an application where the number of increments on a counter far outnumbers the number of times the counter is used or read. For these type of applications, it will be very beneficial to not have to read in the counter from disk before it can be incremented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.