There is no RLL (row level locking) in HBase , all locks- are region-wide.
This is the issue I am going to address
in a separate JIRA.
Example from HRegion.append
// Lock row
startRegionOperation(Operation.APPEND);
Regards,
-Vladimir
On Fri, Sep 12, 2014 at 11:57 AM, Vladimir Rodionov <[email protected]>
wrote:
> 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
>>
>
>
