[
https://issues.apache.org/jira/browse/HBASE-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14391532#comment-14391532
]
Lars Hofhansl commented on HBASE-13378:
---------------------------------------
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)
