hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: HBase reads, isolation levels and RegionScanner internal locking
Date Fri, 12 Sep 2014 18:04:21 GMT
On Thu, Sep 11, 2014 at 3:58 PM, Vladimir Rodionov <vladrodionov@gmail.com>
wrote:

> Hi, all
>
> We have two isolation levels in (used to be in Scan) in Query now. See:
> https://issues.apache.org/jira/browse/HBASE-11936
>
> I moved isolation levels API from Scan upward to Query class. The reason:
> this API was not available for Get operations. The rationals? Improve
> performance of get and multi-gets over the same region.
>
> As many of you aware, RegionScannerImpl is heavily synchronized on internal
> region's lock.  Now some questions:
>
> 1. Is it safe to bypass this locking (in next() call) in READ_UNCOMMITTED
> mode?

We will do all necessary checks, of course, before calling nextRaw().
> 2. What was the reason of this locking in a first place for reads in
> READ_COMMITTED mode? Except obvious - no-dirty-reads allowed? Can someone
> tell me what else bad can happen?
>


There is only the obvious (that I know of) Vladimir.  We've been so fixated
on ensuring consistent view on a row, we've not done the work to allow
other read types. I'm not sure what would happen if you were to skirt row
lock.  Try hacking on TestAtomicOperation to undo lock and see what happens?

St.Ack

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message