[
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
(v6.2#6252)
