hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Sharma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7093) Couple Increments/Appends with Put/Delete(s)
Date Thu, 15 Nov 2012 18:32:15 GMT

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

Varun Sharma commented on HBASE-7093:

Hi Ted,

Thanks for taking a look.

HBASE 4583 forced appends and increments to wait for previous Memstore transactions to complete
since otherwise we could have potential race conditions with puts into that same column.

However, if we allow Append(s) as part of MutateRow - this variable essentially allows us
to do this "wait for previous memstore" transaction thing exactly once. So, we pass to prepareAppend
whether we have historically advanced the memstore, if not, then prepareAppend shall advance
it for us. Maybe i should rename the argument and variable in the process() call to be - "waitForPreviousMemstoreWrite"
and the local variable to be advancedMemstoreWrite...
> Couple Increments/Appends with Put/Delete(s)
> --------------------------------------------
>                 Key: HBASE-7093
>                 URL: https://issues.apache.org/jira/browse/HBASE-7093
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.96.0
>            Reporter: Varun Sharma
>            Assignee: Varun Sharma
>         Attachments: 7093-v1.txt
> See related issue - https://issues.apache.org/jira/browse/HBASE-4583
> Currently, we cannot bundle increment/append with put/delete operations. The above JIRA
MVCC'izes the increment/append operations.
> One issue is that increment(s)/append(s) are not idempotent and hence repeating the transaction
has an associated issue of leading to incorrect value/append results. This could be solved
by passing additional tokens as part of the append(s).
> One possible high level approach could be:
> 1) Class IncrementMutation which inherits from Increment and Mutation
> 2) In the mutateRow call, we add a case for "IncrementMutation" object
> 3) Factor out the code wrapped inside the "lock and MVCC" from increment() function to
> 4) Call internalIncrement from mutateRow and increment()

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message