Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 89273 invoked from network); 28 Apr 2010 14:34:55 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Apr 2010 14:34:55 -0000 Received: (qmail 4580 invoked by uid 500); 28 Apr 2010 14:34:54 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 4561 invoked by uid 500); 28 Apr 2010 14:34:54 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 4553 invoked by uid 99); 28 Apr 2010 14:34:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Apr 2010 14:34:54 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates 74.125.82.172 as permitted sender) Received: from [74.125.82.172] (HELO mail-wy0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Apr 2010 14:34:48 +0000 Received: by wyb35 with SMTP id 35so4518473wyb.31 for ; Wed, 28 Apr 2010 07:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=KMjPNMSCdIqZAy0FClE+wodr+4Lj3NQvioBxnMsjN7k=; b=OQAPr2FHmi+DIK13WFi8c5AKpLywy2bK/4cKiwXWEvS6sSEB76Lu+MJww35ZUcuyxT MkC43gNwkqr6y6xnxK8QNxfqj/eyDljI5Py47Xuuu38/a1DTa2CpshCGpfPcu2ydCy6D rgqtnGF0n8iMF8ATf1dPCkudvn1LvXRstHcLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=LloSMBRE9SiNWDXkmEhLGFYgS+HlBuyrPkToPtyHRYcaiVgIKdWtS4U3VQR0yjzFDC 4o4kCBhlOEF40rX2x4j1lbMcKr6U53Qp0BTQtPzPyKzwynxQfZ6+/uz7UrSbGaaJIHX/ MnXrDPInUeHzoo9TeruekqUxFIkafuCtuicAE= Received: by 10.216.154.84 with SMTP id g62mr2140436wek.176.1272465268218; Wed, 28 Apr 2010 07:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.22.10 with HTTP; Wed, 28 Apr 2010 07:34:08 -0700 (PDT) In-Reply-To: References: From: Jonathan Ellis Date: Wed, 28 Apr 2010 09:34:08 -0500 Message-ID: Subject: Re: Detailed behavior of insert() operation? To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 2010/4/28 Roland H=E4nel : > Two clients insert the same key/colum with different values at the same > time: > > =A0=A0 client A does insert(keyspace,=A0key_1, > column_name_1,=A0value_A,=A0timestamp_1,=A0consistency_level.QUORUM) > =A0=A0 client B does insert(keyspace,=A0key_1, > column_name_1,=A0value_B,=A0timestamp_1,=A0consistency_level.QUORUM) > > After that, both clients read their value: > > =A0=A0 client A does > get(keyspace,=A0key_1,=A0column_name_1,=A0consistency_level.QUORUM) > =A0=A0 client B does > get(keyspace,=A0key_1,=A0column_name_1,=A0consistency_level.QUORUM) > > It is obvious that since the insert happens 'at the same time', i.e. with > the same timestamp, we cannot say > which value (value_A or value_B) gets written to the row. However, do we > have a guarantee that either value_A > or value_B is written, and that both read operations will return the same > result? The guarantee is that "eventually" you will get a consistent result. Say both writes overlap such that value A is present on replicas R1 and R2, and value B is present on replica R3 (after both writes complete). Simultaneous read operations could then both attempt to "repair" the other nodes, and again there could be overlap, resulting in still 2 values present, possibly on different nodes this time. So: you can see different values on reads when there are two "simultaneous" writes, and this can continue in the worst-case scenario until one read's repair can finish before another begins. --=20 Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com