[ 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)