[
https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738470#action_12738470
]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
Really!
I care about request atomicity, because if my client goes away, I have no way
to replay the remainder of the request series, regardless of what the
operations were. The writes are individually idempotent, but I still have to
know what they are, because they can't be reconstructed in a new request.
Better in that case if nothing was applied at all, so I want to fire either a
bundle or nothing to the server. I'll trust that the server makes a best effort
to apply the batch once received, and not worry too much about failure
conditions.
I'm not trying to guarantee some kind of robust atomicity; I'm just trying to
make the system more generally reliable in the presence of extremely unreliable
clients which could fail within a series of sequential related writes.
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> I need all possible mutations to be able to be bundled into a generic
> batchMutation, and sent as one operation.
> In the absence of database constraints, this gives you all the benefits of
> transactions with none of the implementation pain. All I care about is
> whether a bundle of updates reaches the server atomically, mitigating issues
> with unreliable client VMs, and allowing the client to "roll back" a set of
> operations by merely discarding the batch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
