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 Fri, 21 May 2010 17:05:18 GMT

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

Todd Lipcon commented on HBASE-2332:

bq. So if a client holds a lock, blocks for some reason (swapping, etc) that is taking an
indeterminate amount of time, and then loses its lock lease, the next lock holder is guaranteed
that all future actions taken by the previous holder using the expired lock will fail

Only on that particular row, though, since the leases are per-regionserver.

bq. Is there an objection to just making row lock acquisition non-blocking and implementing
all the blocking/retry/backoff client-side?

I definitely agree that this solves much of the scalability issue. Some of the other issues
above still remain, though - for example, we don't currently persist lock acquisition/release
in the HLog, so if the region moves to a new server, everyone loses their locks.

Regarding the use case of moving rows, what does your lock based algorithm look like? Will
it proceed correctly in the case of RS failure, loss of lease at arbitrary points, and failure
of client?

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

View raw message