[
https://issues.apache.org/jira/browse/CASSANDRA-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965373#action_12965373
]
Peter Schuller commented on CASSANDRA-1780:
-------------------------------------------
Jonathan: My confusion was with the atomicity guarantee in this case. I do see
that memtables are okay to be flushed prior to the data being in commit log;
what I was worried about was partial or complete visibility of the data due to
it being in-memory in a memtable, followed by a crash. In this case updates
would be partially or completely visible followed by disappearing and never
coming back, from the perspective of an outside observer.
I am aware isolation is not guaranteed; but I never considered that lack of
isolation also allows rolling back data that was already seen (in addition to
allowing a client to see partially applied data). It's not quite obvious to me
why this is inherent in the "atomic but not isolated" guarantee, but certainly
seems like a suitable trade-off for the performance implications of running in
periodic sync mode.
> periodic + flush commitlog mode
> -------------------------------
>
> Key: CASSANDRA-1780
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1780
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments: 1780.txt
>
>
> periodic-sync commitlog mode only flushes before it syncs, which means its
> best case durability is very similar to its worst case. if we had a mode
> that flushed but did not sync then it would only lose data for actual power
> failures.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
