Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <792360077.1251822752807.JavaMail.jira@brutus>
Date: Tue, 1 Sep 2009 09:32:32 -0700 (PDT)
From: "stack (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-1806) Scanners do not respect row locks;
 scanner view could return a skewed view on row if ongoing update
In-Reply-To: <459912136.1251780332737.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HBASE-1806:
------------------------------

I don't think we can fix this w/ tools available to us in 0.20 hbase other than by doing the ugly stuff we're doing over in hbase-1784.  This is a contrary issue.  ZK will help but will not be enough (IMO).

> Scanners do not respect row locks; scanner view could return a skewed view on row if ongoing update
> ---------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-1806
>                 URL: https://issues.apache.org/jira/browse/HBASE-1806
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
>
> What I'm seeing is that BaseScanner misses updates made by an update milliseconds before -- even hundreds of milliseconds before.  See hbase-1784 where I'm seeing double-assignment of regions.
> Scanners do not respect row locks.  They should else could return a row with partial updates committed.  What if a .META. region has tens of storefiles and a scan does a get full row which takes a long time.  Say an update comes in during this read.  First it will go in because no row lock is outstanding.  Second, we'll miss the edit given we look at things in order -- memstore, then each storefile down to the oldest.  What if the update is followed by an update of server state; e.g. region is moved out of intransition state?  And inside in same server, say the master, it makes decisions dependent on what it sees when it does a scanner#next; e.g. BaseScanner checking for assignment?

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