hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HBASE-2584) Add support for tryLock - non-blocking row lock acquisition
Date Sat, 19 Jul 2014 00:32:39 GMT

     [ https://issues.apache.org/jira/browse/HBASE-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Andrew Purtell resolved HBASE-2584.

      Resolution: Not a Problem
    Release Note:   (was: Adds support for tryLock in HTable)
    Hadoop Flags:   (was: Incompatible change)

We've removed user row locks

> Add support for tryLock - non-blocking row lock acquisition
> -----------------------------------------------------------
>                 Key: HBASE-2584
>                 URL: https://issues.apache.org/jira/browse/HBASE-2584
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Michael Dalton
>         Attachments: 2584.patch
> Currently HBase clients can only acquire row locks via the blocking lockRow() method
in HTable. As ryan described on the mailing list, relying on this method in rare highly contended
situations can lead to (temporary) deadlock. This deadlock occurs if a client acquires the
lock, and a large number of other clients attempt to acquire the lock and block. Each blocked
client awaiting lock acquisition consumes one of the limited I/O handler threads on the regionserver.
When lock holder wishes to release the lock, he will be unable to as all I/O threads are currently
serving clients that are blocking on lock acquisition -- and thus no I/O threads are open
to process the unlock request.
> To avoid deadlock situations such as the one described above, I have added support for
'tryLock' in HTable (and on the regionservers). The 'tryLock' method will attempt to acquire
a row lock. In the event that a lock is already held, tryLock immediately returns null rather
than blocking and waiting for the lock to be acquire. Clients can then implement their own
backoff/retry policy to re-acquire the lock, determine their own timeout values, etc based
on their application performance characteristics rather than block on the regionserver and
tie up precious I/O regionserver handler threads for an indefinite amount of time. 

This message was sent by Atlassian JIRA

View raw message