[
https://issues.apache.org/jira/browse/HBASE-11965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132269#comment-14132269
]
Vladimir Rodionov commented on HBASE-11965:
-------------------------------------------
Yes and no. First of all, this is not the only synchronization point in
RegionScannerImpl. It has synchronized block in constructor. Second of all,
acquiring/releasing read lock is not free, of course. Third of all, combination
of *startRegionOperation*/*closeRegionOperation* is heavy not only because of
locking - there are at least two objects instantiated *new RegionOperation()*.
Multi-treaded object allocation in Java is still a hot research area.
And last one... All mutations on a region will be blocked until last read lock
released. Bad.
> Optimize locking in HRegion
> ---------------------------
>
> Key: HBASE-11965
> URL: https://issues.apache.org/jira/browse/HBASE-11965
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
>
> Described in this thread:
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201409.mbox/%3CCAAg3a2qmWJtQbdAk7PrX%2BW8SZWxsYhNggM5f2RNkGTXUri34YQ%40mail.gmail.com%3E
> *startRegionOperation* and *closeRegionOperation* in HRegion acquires and
> releases region-wide lock. The locking happens for every mutation, read and
> scan next. This is a serious bottleneck if we do:
> * Mutli - get on a same region.
> * Run multiple scanners on same region.
> * Do scan during compaction.
> * Access region simultaneously from different threads (most generic case)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
