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 <[email protected]> wrote: > On Thu, Sep 11, 2014 at 3:58 PM, Vladimir Rodionov <[email protected] > > > 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 >
