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

Hiroshi Ikeda commented on HBASE-15716:
---------------------------------------

{code}
+      // If the isolation level is READ_UNCOMMITTED, should we just not bother 
registering?
+      // This was suggested by Hiroshi Ikeda. I was thinking that the 
READ_UNCOMMITTED applied to
+      // the frontier of updates, not the rear where Cells might be dropped 
because too many
+      // versions or beyond the TTL.
       synchronized(scannerReadPoints) {
         this.readPt = getReadpoint(isolationLevel);
         scannerReadPoints.put(this, this.readPt);
{code}

I'm not sure about READ_UNCOMMITTED in detail, but I feel we should take the 
current mvcc.memstoreReadPoint() regardless of isolationLevel, otherwise cells 
can be freely dropped before or while scanning when using READ_UNCOMMITTED.

> HRegion#RegionScannerImpl scannerReadPoints synchronization constrains random 
> read
> ----------------------------------------------------------------------------------
>
>                 Key: HBASE-15716
>                 URL: https://issues.apache.org/jira/browse/HBASE-15716
>             Project: HBase
>          Issue Type: Bug
>          Components: Performance
>            Reporter: stack
>            Assignee: stack
>         Attachments: 15716.prune.synchronizations.patch, 
> 15716.prune.synchronizations.v3.patch, 15716.prune.synchronizations.v4.patch, 
> 15716.prune.synchronizations.v4.patch, 15716.wip.more_to_be_done.patch, 
> Screen Shot 2016-04-26 at 2.05.45 PM.png, Screen Shot 2016-04-26 at 2.06.14 
> PM.png, Screen Shot 2016-04-26 at 2.07.06 PM.png, Screen Shot 2016-04-26 at 
> 2.25.26 PM.png, Screen Shot 2016-04-26 at 6.02.29 PM.png, Screen Shot 
> 2016-04-27 at 9.49.35 AM.png, 
> current-branch-1.vs.NoSynchronization.vs.Patch.png, hits.png, 
> remove_cslm.patch
>
>
> Here is a [~lhofhansl] special.
> When we construct the region scanner, we get our read point and then store it 
> with the scanner instance in a Region scoped CSLM. This is done under a 
> synchronize on the CSLM.
> This synchronize on a region-scoped Map creating region scanners is the 
> outstanding point of lock contention according to flight recorder (My work 
> load is workload c, random reads).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to