cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Weaver (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-336) Merge batchmutation types and support batched deletes
Date Mon, 03 Aug 2009 18:13:15 GMT


Evan Weaver commented on CASSANDRA-336:


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:
>             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.

View raw message