[
https://issues.apache.org/jira/browse/HBASE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14986622#comment-14986622
]
Jerry He commented on HBASE-14575:
----------------------------------
There is a complex logic with the writestate in HRegion:
{code}
/*
* Data structure of write state flags used coordinating flushes,
* compactions and closes.
*/
static class WriteState {
// Set while a memstore flush is happening.
volatile boolean flushing = false;
// Set when a flush has been requested.
volatile boolean flushRequested = false;
// Number of compactions running.
volatile int compacting = 0;
// Gets set in close. If set, cannot compact or flush again.
volatile boolean writesEnabled = true;
{code}
I am curious how this duplicates the region level lock we are trying to relax?
Maybe the writestate is taking care of things already?
> Reduce scope of compactions holding region lock
> -----------------------------------------------
>
> Key: HBASE-14575
> URL: https://issues.apache.org/jira/browse/HBASE-14575
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction, regionserver
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Attachments: 14575-v1.patch, 14575-v2.patch, 14575-v3.patch,
> 14575-v4.patch, 14575.v00.patch
>
>
> Per [~devaraj]'s idea on parent issue, let's see if we can reduce the scope
> of critical section under which compactions hold the region read lock.
> Here is summary from parent issue:
> Another idea is we can reduce the scope of when the read lock is held during
> compaction. In theory the compactor only needs a region read lock while
> deciding what files to compact and at the time of committing the compaction.
> We're protected from the case of region close events because compactions are
> checking (every 10k bytes written) if the store has been closed in order to
> abort in such a case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
