Vlad, I understand. However several of the HBase committers aren’t really schooled in RDBMS design.
And again, the older (going back to 0.23 ) use of the term RLL isn’t relational RLL and when you start to talk about isolation you’re getting in to the RDBMS RLL So you really need to define what you mean when you say RLL. I don’t want to assume one thing when you meant another. Just like talking about salts. ;-) On Sep 12, 2014, at 5:53 PM, Vladimir Rodionov <[email protected]> wrote: > Michael, this is HBase developers mailing list. > > -Vladimir > > > > > On Fri, Sep 12, 2014 at 12:08 AM, Michael Segel <[email protected]> > wrote: > >> Silly question… >> >> HBase uses the term RLL (row level locking) to make the writes to a row >> atomic. >> >> When you start to get in to isolation, RLL takes on a different meaning. >> >> So now you have to better define what do you mean by locking. Are you >> taking about HBase RLL, >> or are you talking about Transactional RLL ( RDBMS RLL) ? >> >> >> On Sep 11, 2014, at 11: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? >>> >>> -Vladimir >> >>
