[ 
https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053453#comment-16053453
 ] 

Yu Li commented on HBASE-18144:
-------------------------------

bq. Any idea which issue changed this way? Yu Li
It's HBASE-12751/HBASE-14465, which removed the {{boolean shouldBlock = 
numReadyToWrite == 0;}} logic. And our boss stack has clarified reason for the 
change.

Happen to know this since I've backported this "Allow Rowlock to be reader 
writer" feature to our customized 1.1.2 (smile). As mentioned before, in our 
search scenario we don't have increment requests so luckily never ran into this 
issue. [~anoop.hbase]

bq.  Better to have the batch fail quickly with a bunch of read-lock successes 
than have it wait (deadlock) for 30 seconds at a time just because the batch 
had a write lock in the mix that it was unable to attain in time; better to 
fail fast and then retry on a new rpc?
Exactly, and I think the old *shouldBlock* trick could achieve this, which 
means we won't wait for any write lock if we're already holding read locks in 
the batch. And if we failed to attain any read lock in mid of one 
doMiniBatchMuation round, we will fail fast (return null lock and break the 
while loop, write those edits with locks successfully attained, release locks, 
then return). In this case {{batchOp.isDone}} in {{batchMutate}} returns false 
and we will try another doMiniBatchMutation. Allan's HBASE-18233 patch shows 
the logic in codes.

IMHO, all simple put (single or batch) only takes read lock, while 
append/increment/checkAndXXX takes write lock. One put batch will be split into 
multiple rounds if it failed to attain any read lock in doMiniBatchMutation, 
after each round it will release the taken read lock so won't block later 
operations. Maybe I'm not getting your point and could you further clarify if 
so boss? [~stack]? Thanks.

> Forward-port the old exclusive row lock; there are scenarios where it 
> performs better
> -------------------------------------------------------------------------------------
>
>                 Key: HBASE-18144
>                 URL: https://issues.apache.org/jira/browse/HBASE-18144
>             Project: HBase
>          Issue Type: Bug
>          Components: Increment
>    Affects Versions: 1.2.5
>            Reporter: stack
>            Assignee: stack
>             Fix For: 2.0.0, 1.3.2, 1.2.7
>
>         Attachments: DisorderedBatchAndIncrementUT.patch, 
> HBASE-18144.master.001.patch
>
>
> Description to follow.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to