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

Andrew Purtell commented on HBASE-1806:
---------------------------------------

I've always accepted this fact about scanners. It's debatable if we should take 
the performance hit to consider transactional semantics of any kind for 
scanners. Could be enough to just document that TableMappers should test for 
inconsistent state from the application's perspective and ignore the record as 
appropriate. Can get another shot at it during the next job. Of course master 
scanners are a special case. I wonder why this did not occur to me before... 
Moving META into ZK is the appropriate strategy to use for this and other 
reasons 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.

Reply via email to