[ 
https://issues.apache.org/jira/browse/CASSANDRA-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028374#comment-13028374
 ] 

Jonathan Ellis commented on CASSANDRA-1954:
-------------------------------------------

I think the approach here also has a subtle problem keeping index CFs in sync 
with the data CFs: if I mark a given replay position in the data CF, then I 
need to guarantee that the index updates for all mutations before that position 
are flushed along with the the data updates, since index updates are made 
during data mutation and not recorded separately in the CL.

Since we do not block other writing threads while switching memtables, I think 
it's possible that we violate that requirement here.

> 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
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.0
>
>         Attachments: 
> 0001-Double-check-in-maybeSwitchMemtable-to-minimize-writeL.txt, 
> 0001-Remove-flusherLock-readLock.patch, 1954-0.7-v2.txt, 1954-v2.txt, 
> 1954_trunk.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> {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

Reply via email to