hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2332) Remove client-exposed row locks from region server
Date Tue, 16 Mar 2010 22:41:27 GMT

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


Mime
View raw message