hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Rodionov <vladrodio...@gmail.com>
Subject Re: HBase reads, isolation levels and RegionScanner internal locking
Date Fri, 12 Sep 2014 18:57:21 GMT
According to Bible:
http://hbase.apache.org/acid-semantics.html

HBase declares that all row reads are consistent - partial reads for rows
are not possible.

[
Consistency and Isolation

   1. All rows returned via any access API will consist of a complete row
   that existed at some point in the table's history.
   2. This is true across column families - i.e a get of a full row that
   occurs concurrent with some mutations 1,2,3,4,5 will return a complete row
   that existed at some point in time between mutation i and i+1 for some i
   between 1 and 5.
   3. The state of a row will only move forward through the history of
   edits to it.

]

In this case, there is no much sense in READ_UNCOMMITTED per se.

-Vladimir


On Fri, Sep 12, 2014 at 11:04 AM, Stack <stack@duboce.net> wrote:

> 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