Ah I see. That makes sense.
And it doesn't have to anything with the read requests going on in parallel 
with write requests, right?
I mean we read the data from memtable depending on whatever has been written 
into memtable so far and return it to the client (of course including SSTable 
read and timestamp comparison etc.)

-----Original Message-----
From: Benedict Elliott Smith [mailto:bened...@apache.org] 
Sent: Tuesday, February 13, 2018 2:25 PM
To: dev@cassandra.apache.org
Subject: Re: Use of OpOrder in memtable

If you look closely, there can be multiple memtables extant at once.  While all 
"new" writes are routed to the latest memtable, there may still be writes that 
have begun but not yet completed.  The memtable cannot be flushed until any 
stragglers have completed, and some stragglers *may* still need to be routed to 
their designated memtable (if they had only just begun when the flush 
triggered).  It helps avoid these race conditions on either side of the 

On 13 February 2018 at 22:09, Tyagi, Preetika <preetika.ty...@intel.com>

> Hi all,
> I'm trying to understand the behavior of memtable when writes/flush 
> operations are going on in parallel.
> In my understanding, once a memtable is full it is queued for flushing 
> and a new memtable is created for ongoing write operations.
> However, I was looking at the code and it looks like the OpOrder class 
> is used (don't understand all details) to ensure the synchronization 
> between producers (writes) and consumers (batch flushes).
> So I am a bit confused about when exactly it is needed. There will 
> always be only one latest memtable for write operations and all old 
> memtables are flushed so where this producer/consumer interaction on 
> the same memtable is needed?
> Thanks,
> Preetika

Reply via email to