hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JH Lin" <match20...@163.com>
Subject Re:Re: why use at least one rowlock to update
Date Tue, 29 Aug 2017 04:21:39 GMT
thanks all your resonses.
i think row lock has been implemented by MVCC in hbase at that release.
@Josh ,in MVCC there is a variable named 'memstoreWrite' to achieve 'across-transaction' isolation.for
reads,the readers will not see the data writen at T2(memstoreWrite) before the memstoreRead
is inreased to that sequential number while all writes are queued .
@Anoop ,by futher reading,there is possible to continue updating w/o any row locks for any
minibatch.code block from src:
//retrieve rowlocks loop
for ( r in rows){
  if (acquiredLockId == null) { 

          assert !shouldBlock : "Should never fail to get lock when blocking"; 

          //--note here:it is used break instead of 'return' to quit the loop

          break; // stop acquiring more rows for this batch 


write to memstore
write to wal
   so is it a little obsolete between src code and later design solution?
  one more thing,why does it first write to mem then wal instead of the opposite order? for
restoring more conveniently when failures?

在2017年08月29 00时56分, "Anoop John"<anoop.hbase@gmail.com>写道:

> since  if i have 10 rows to update,then it means that 9 rows have no rowlocks.so is 'at
least one rowlock' more symbolic than practical significane?

Pls note that it is doMiniBatchMutation.  10 rows there in ur batch.
The batch might get complete in many mini batches.  When one mini
batch is mutated, all row locks in that mini batch will be obtained.
So there is no mutate of a row with out getting its lock


On Mon, Aug 28, 2017 at 9:53 PM, Josh Elser <elserj@apache.org> wrote:
> Please be patient when waiting for a response. Apache HBase is made up of
> community volunteers. Your expectation should be on the order of many hours
> (although, we strive to be faster).
> I'd recommend that you begin by looking at a newer release than 0.94.2 as
> there have likely been over 50 (guessing) newer releases since this release
> was made.
> In general, rowlocks must be acquired to ensure that multiple updates to the
> same row are applied in full. Consider two transactions against the same
> row:
> tx1: row=r1 set a=1, b=1
> tx2: row=r1 set a=2, b=2
> After tx1 and tx2 are both applied, r1 must either have the columns a=1,b=1
> or a=2,b=2. It must not have a=1,b=2 or a=2,b=1. This is why some form of
> mutual exclusion must be applied inside of the RegionServer.
> On 8/28/17 10:06 AM, JH Lin wrote:
>> ping...
>> 在2017年08月28 17时55分, "JH Lin"<match2008s@163.com>写道:
>> hi all,i dived into hbase source these days.when i read at the
>> HRegion#doMiniBatchMutation(...) block then one question flashed in my
>> mind:why did writer use at least one rowlock to implement mutation?(ie.Puts
>> or Deletes etc)
>>   since  if i have 10 rows to update,then it means that 9 rows have no
>> rowlocks.so is 'at least one rowlock' more symbolic than practical
>> significane?
>>   AFAIK now,i think it's used to verify hbase' basic functions eg. rowlock
>> mechanism.
>> ---
>> release:hbase-0.94.2
>> pardon me if it's a bit old,but i just wonder to know its principle inside
>> it.
>> one more thing, my english is poor,so sorry for any typo.
>> many thanks~
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message