Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <1447146811.1249323195096.JavaMail.jira@brutus>
Date: Mon, 3 Aug 2009 11:13:15 -0700 (PDT)
From: "Evan Weaver (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Commented: (CASSANDRA-336) Merge batchmutation types and
 support batched deletes
In-Reply-To: <1025573587.1249316114795.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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