You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Lars Hofhansl (JIRA)" <ji...@apache.org> on 2015/04/01 23:48:53 UTC

[jira] [Comment Edited] (HBASE-13378) RegionScannerImpl synchronized for READ_UNCOMMITTED Isolation Levels

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

Lars Hofhansl edited comment on HBASE-13378 at 4/1/15 9:48 PM:
---------------------------------------------------------------

Looks fine to me.

One interesting bit is: Now we won't hold on versions of Cells read by an READ_UNCOMMITTED scanner (i.e. even while the scanner is active those cells can be removed by a flush or a compaction).

Up to this point READ_UNCOMMITED meant: You might see partially finished rows.
Now it means: You might see partially finished rows, and you may not see cells that have existed when the scanner started.

Not sure how important the 2nd part is, but up to now we guarantee that _all_ scanners see _all_ data that existed when the scanner started. That would no longer be the case.

I do think for READ_UNCOMMITTED that's OK... I.e. all bets are off in that case, but it is a change in behavior.

[~eclark], Kannan and Karthik from Facebook added this back in the days, do you have an opinion?



was (Author: lhofhansl):
Looks fine to me.

One interesting bit is: Now we won't hold on versions of Cells read by an READ_UNCOMMITTED scanner (i.e. even while the scanner is active those cells can be removed by a flush or a compaction).

Up to this point READ_UNCOMMITED meant: You might see partially finished rows.
Now it means: You might see partially finished rows, and you may not see cells that have existed when the scanner started.

Not sure how important the 2nd part is, but up to now we guarantee that _all_ scanners see _all_ data existed when the scanner started. That would no longer be the case.

I do think for READ_UNCOMMITTED that's OK... I.e. all bets are off in that case, but it is a change in behavior.

[~eclark], Kannan and Karthik from Facebook add this back in the days, do you have an opinion?


> RegionScannerImpl synchronized for READ_UNCOMMITTED Isolation Levels
> --------------------------------------------------------------------
>
>                 Key: HBASE-13378
>                 URL: https://issues.apache.org/jira/browse/HBASE-13378
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: John Leach
>            Assignee: John Leach
>            Priority: Minor
>         Attachments: HBASE-13378.txt
>
>   Original Estimate: 2h
>          Time Spent: 2h
>  Remaining Estimate: 0h
>
> This block of code below coupled with the close method could be changed so that READ_UNCOMMITTED does not synchronize.  
> {CODE:JAVA}
>       // synchronize on scannerReadPoints so that nobody calculates
>       // getSmallestReadPoint, before scannerReadPoints is updated.
>       IsolationLevel isolationLevel = scan.getIsolationLevel();
>       synchronized(scannerReadPoints) {
>         this.readPt = getReadpoint(isolationLevel);
>         scannerReadPoints.put(this, this.readPt);
>       }
> {CODE}
> This hotspots for me under heavy get requests.



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