Michael, This is not a row-level locking - it is region-wide lock. This is a major reason of the following performance problems:
1) Multi gets are bad if inside the same region 2) Multiple scanners over the same region are bad 3) Scan during compaction are bad. I need some input from HBase folks here: 1) READ_UNCOMMITTED safe if lock free? 2) Confirmation that region-wide lock is for read consistency only. 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 >
