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