Return-Path: 
 <issues-return-105244-apmail-hbase-issues-archive=hbase.apache.org@hbase.apache.org>
X-Original-To: apmail-hbase-issues-archive@www.apache.org
Delivered-To: apmail-hbase-issues-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 1F91E109F2
	for <apmail-hbase-issues-archive@www.apache.org>;
 Mon, 15 Jul 2013 23:18:51 +0000 (UTC)
Received: (qmail 742 invoked by uid 500); 15 Jul 2013 23:18:50 -0000
Delivered-To: apmail-hbase-issues-archive@hbase.apache.org
Received: (qmail 714 invoked by uid 500); 15 Jul 2013 23:18:50 -0000
Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@hbase.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@hbase.apache.org>
List-Post: <mailto:issues@hbase.apache.org>
List-Id: <issues.hbase.apache.org>
Delivered-To: mailing list issues@hbase.apache.org
Received: (qmail 705 invoked by uid 99); 15 Jul 2013 23:18:50 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Jul 2013 23:18:50 +0000
Date: Mon, 15 Jul 2013 23:18:50 +0000 (UTC)
From: "Dave Latham (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12656386.1373038090017.54369.1373930330842@arcas>
In-Reply-To: <JIRA.12656386.1373038090017@arcas>
References: <JIRA.12656386.1373038090017@arcas>
Subject: [jira] [Updated] (HBASE-8877) Reentrant row locks
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


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

Dave Latham updated HBASE-8877:
-------------------------------

    Attachment: HBASE-8877-refCounts.patch

Reattaching refCounts patch with check to enforce that only the same thread may release a lock that acquired it and so that Hadoop QA checks this file rather than the benchmark results.
                
> Reentrant row locks
> -------------------
>
>                 Key: HBASE-8877
>                 URL: https://issues.apache.org/jira/browse/HBASE-8877
>             Project: HBase
>          Issue Type: Bug
>          Components: Coprocessors, regionserver
>            Reporter: Dave Latham
>            Assignee: Dave Latham
>             Fix For: 0.95.2
>
>         Attachments: hbase-8877-0.94-microbenchmark.txt, HBASE-8877-0.94.patch, HBASE-8877-0.94-v2.patch, HBASE-8877.patch, hbase-8877-refCounts-microbenchmarks.txt, HBASE-8877-refCounts.patch, HBASE-8877-v2.patch, HBASE-8877-v3.patch, hbase-8877-v4-microbenchmark.txt, HBASE-8877-v4.patch, HBASE-8877-v5.patch, HBASE-8877-v6.patch, HBASE-8877-v7.patch
>
>
> HBASE-8806 revealed performance problems with batch mutations failing to reacquire the same row locks.  It looks like HBASE-8806 will use a less intrusive change for 0.94 to have batch mutations track their own row locks and not attempt to reacquire them.  Another approach will be to support reentrant row locks directly.  This allows simplifying a great deal of calling code to no longer track and pass around lock ids.
> One affect this change will have is changing the RegionObserver coprocessor's methods preBatchMutate and postBatchMutate from taking a {{MiniBatchOperationInProgress<Pair<Mutation, Integer>> miniBatchOp}} to taking a {{MiniBatchOperationInProgress<Mutation> miniBatchOp}}.  I don't believe CPs should be relying on these lock ids, but that's a potential incompatibility.

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