[
https://issues.apache.org/jira/browse/HBASE-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835936#comment-13835936
]
Lars Hofhansl edited comment on HBASE-10060 at 12/1/13 3:20 AM:
----------------------------------------------------------------
So to be specific we use the RegionScannerImpl, which already takes a lock for
"normal" scans. For compactions/flushes we lock the scanner for the entire
operation ahead of time. For this to work we need part of HBASE-9949 in 0.96
and 0.94 (the part where we also call updateReaders StoreScanner on behalf on
compactions and flushes). Then we can use the lock on StoreScanner.updateReader
to delay replacing the readers.
Might be easiest to just explain with a patch :)
was (Author: lhofhansl):
So to be specific we use the RegionScannerImpl, which already takes a lock for
"normal" scans. For compactions/flushes we lock the scanner for the entire
operation ahead of time. For this to work we need part of HBASE-9949 in 0.96
and 0.94 (the part where we also call updateReaders StoreScanner on behalf on
compactions and flushes). Then we can use the lock on StoreScanner.updateReader
to delay replacing the readers.
Might be easiest to j
> 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)
