[jira] Commented: (HBASE-2332) Remove client-exposed row locks from region server

["Todd Lipcon (JIRA)" <ji...@apache.org>]

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

Todd Lipcon commented on HBASE-2332:
------------------------------------

To summarize some of the thoughts from the other JIRA (plus some conversation Ryan and I have been having):

- Row locks provided by HBase are not very scalable, since clients blocked on locks tie up valuable regionserver threads.
- Row locks may not be correct in the current implementation, since they aren't logged in the HLog and thus don't survive region failover
- We provide a compare-and-swap primitive, which is sufficient to achieve the same effect as row locks from the client side (using a spin lock pattern)

We'll still need row locking internally to achieve atomic operations (see HBASE-2294 for more details). However, these should be a private implementation detail.

Some benefits we can get by dropping the external exposure of the row locks:
- The guarantees determined in HBASE-2294 may be achievable through more efficient means - eg lock free data structures, MVCC, etc.
- Externally exposed row locks add complexity both to implementation and APIs (eg being able to specify an existing row lock id to other mutations)
- Though we still need internal row locks, we can most likely get away with multiplexing multiple rows to a single lock. For example, we can have a few hundred locks in an array, then hash rows onto that array. Since internal locks are only held very shortly (enough time to mutate the memstore and sync), and only one row at a time, this should be safe and more memory-efficient.

If the row lock API is deemed important for users, we can implement it client-side using the CAS pattern. To make it more efficient, we could add a signaling mechanism - more details on this in the future if it comes up.

> Remove client-exposed row locks from region server
> --------------------------------------------------
>
>                 Key: HBASE-2332
>                 URL: https://issues.apache.org/jira/browse/HBASE-2332
>             Project: Hadoop HBase
>          Issue Type: Improvement
>          Components: client, regionserver
>            Reporter: Todd Lipcon
>             Fix For: 0.21.0
>
>
> Discussion in HBASE-2294 has surfaced that the client-exposed row lock feature in the HBase API may not be scalable/necessary. Additionally there are some benefits we can reap by removing the feature (or pushing it into the client).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.