[
https://issues.apache.org/jira/browse/HBASE-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835918#comment-13835918
]
Lars Hofhansl commented on HBASE-10060:
---------------------------------------
A possible solution is delegate the locks to the outside.
* During a compaction or flush we'd lock the StoreScanner object for the
duration of the compaction/flush. When we call updateReaders we'd attempts to
lock the StoreScanner, and thus delay the update of the readers until after the
compaction has finished.
* For a "normal" scan we'd delegate the locking to the enclosing
RegionScannerImpl.
That way there is no repeating lock/unlock during frequent calls to
StoreScanner.peek/next/seek/etc.
It would also force delay updating the readers until it's safe to do so without
any complicating reference counting logic.
> Unsynchronized scanning
> -----------------------
>
> Key: HBASE-10060
> URL: https://issues.apache.org/jira/browse/HBASE-10060
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
>
> HBASE-10015 has some lengthy discussion. The solution there ended up
> replacing synchronized with ReentrantLock, which - somewhat surprisingly -
> yielded a non-trivial improvement for tall tables.
> The goal should be to avoid locking in StoreScanner at all. StoreScanner is
> only accessed by a single thread *except* when we have a concurrent flush or
> a compaction, which is rare (we'd acquire and release the lock millions of
> times per second, and compact/flush a few time an hour at the most).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
