[
https://issues.apache.org/jira/browse/HBASE-17434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15810016#comment-15810016
]
Eshcar Hillel commented on HBASE-17434:
---------------------------------------
I also prefer read-write lock over an exclusive lock when there is a potential
performance boost. However I don't think this is the case.
Flush and in-memory compaction which invoke getVersionedList/Tail later invoke
swap. These operations are only once in a while, so it is not the case where we
have multiple concurrent (read-only) operations contending on the lock and a
read lock can reduce the contention.
On the flip side using ReentrantReadWriteLock adds an additional lock instead
of using existing locks as in the synchronize mechanism (and the code is more
complicated with the try-final blocks).
> New Synchronization Scheme for Compaction Pipeline
> --------------------------------------------------
>
> Key: HBASE-17434
> URL: https://issues.apache.org/jira/browse/HBASE-17434
> Project: HBase
> Issue Type: Bug
> Reporter: Eshcar Hillel
> Assignee: Eshcar Hillel
> Attachments: HBASE-17434-V01.patch, HBASE-17434-V02.patch
>
>
> A new copyOnWrite synchronization scheme is introduced for the compaction
> pipeline.
> The new scheme is better since it removes the lock from getSegments() which
> is invoked in every get and scan operation, and it reduces the number of
> LinkedList objects that are created at runtime, thus can reduce GC (not by
> much, but still...).
> In addition, it fixes the method getTailSize() in compaction pipeline. This
> method creates a MemstoreSize object which comprises the data size and the
> overhead size of the segment and needs to be atomic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
