[
https://issues.apache.org/jira/browse/CASSANDRA-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995277#comment-12995277
]
Sylvain Lebresne commented on CASSANDRA-1954:
---------------------------------------------
Correct me if I am wrong but I think there is a 2 things:
* We need to ensure that we call the discard of the commmit context post-flush
in the same order that we got the context pre-flush.
A lock is fine, especially if we diminish contention on it with double-checking
or with an atomic boolean. That this block all writes however seems
unnecessary. Why lock the read-lock during write (for that purpose I mean)? As
long as we get the commit log context and schedule the post-flush task before
changing the active memtable, we should be right. We may have to replay a tiny
bit more, since a few write will go into the being flushed memtable after we
got the context, but we won't lose any.
On a related note, why I understand why we want to preserve this
'pre-flush/post-flush' order er column family, I'm not sure I understand why it
must be global since the commit log header distinguishes between the different
CFs ?
* We need to keep writes out of being-flushed memtables.
For that, we can use per-memtable counters and make flush start by waiting on
the counter to reach 0.
Am I missing something obvious here ?
As for the View structure proposed by Stu in the previous comment, this could
actually be a quite reasonable solution for CASSANDRA-2105 so I'll probably
give that a shot too in this context.
> Double-check or replace RRW memtable lock
> -----------------------------------------
>
> Key: CASSANDRA-1954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1954
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Priority: Minor
> Attachments:
> 0001-Double-check-in-maybeSwitchMemtable-to-minimize-writeL.txt
>
>
> {quote}...when a Memtable reaches its threshold, up to (all) N write threads
> will often notice, and race to acquire the writeLock in order to freeze the
> memtable. This means that we do way more writeLock acquisitions than we need
> to...{quote}
> See CASSANDRA-1930 for backstory, but adding double checking inside a read
> lock before trying to re-entrantly acquire the writelock would eliminate most
> of these excess writelock acquisitions.
> Alternatively, we should explore removing locking from these structures
> entirely, and replacing the writeLock acquisition with a per-memtable counter
> of active threads.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
