Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E0434FF.2080702@dude.podzone.net>
Date: Fri, 24 Jun 2011 00:55:59 -0600
From: AJ <aj@dude.podzone.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Cassandra ACID
Content-Type: multipart/alternative;
 boundary="------------040601070305030006030201"

This is a multi-part message in MIME format.
--------------040601070305030006030201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Can any Cassandra contributors/guru's confirm my understanding of 
Cassandra's degree of support for the ACID properties?

I provide official references when known.  Please let me know if I 
missed some good official documentation.

*Atomicity*
All individual writes are atomic at the row level.  So, a batch mutate 
for one specific key will apply updates to all the columns for that one 
specific row atomically.  If part of the single-key batch update fails, 
then all of the updates will be reverted since they all pertained to one 
key/row.  Notice, I said 'reverted' not 'rolled back'.  Note: atomicity 
and isolation are related to the topic of transactions but one does not 
imply the other.  Even though row updates are atomic, they are not 
isolated from other users' updates or reads.
Refs: http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic

*Consistency*
If you want 100% consistency, use consistency level QUORUM for both 
reads and writes and EACH_QUORUM in a multi-dc scenario.
Refs: http://wiki.apache.org/cassandra/ArchitectureOverview

*Isolation*
NOTHING is isolated; because there is no transaction support in the 
first place.  This means that two or more clients can update the same 
row at the same time.  Their updates of the same or different columns 
may be interleaved and leave the row in a state that may not make sense 
depending on your application.  Note: this doesn't mean to say that two 
updates of the same column will be corrupted, obviously; columns are the 
smallest atomic unit ('atomic' in the more general thread-safe context).
Refs: None that directly address this explicitly and clearly and in one 
place.

*Durability*
Updates are made durable by the use of the commit log.  No worries here.
Refs: Plenty.

--------------040601070305030006030201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Can any Cassandra contributors/guru's confirm my understanding of
    Cassandra's degree of support for the ACID properties?<br>
    <br>
    I provide official references when known.&nbsp; Please let me know if I
    missed some good
    official documentation.<br>
    <br>
    <b>Atomicity</b><br>
    All individual writes are atomic at the row level.&nbsp; So, a batch
    mutate for one specific key will apply updates to all the columns
    for that one specific row atomically.&nbsp; If part of the single-key
    batch update fails, then all of the updates will be reverted since
    they all pertained to one key/row.&nbsp; Notice, I said 'reverted' not
    'rolled back'.&nbsp; Note: atomicity and isolation are related to the
    topic of transactions but one does not imply the other.&nbsp; Even though
    row updates are atomic, they are not isolated from other users'
    updates or reads.&nbsp;&nbsp;&nbsp; <br>
    Refs: <a class="moz-txt-link-freetext"
      href="http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic">http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic</a><br>
    <br>
    <b>Consistency</b><br>
    If you want 100% consistency, use consistency level QUORUM for both
    reads and writes and EACH_QUORUM in a multi-dc scenario.&nbsp; <br>
    Refs: <a class="moz-txt-link-freetext"
      href="http://wiki.apache.org/cassandra/ArchitectureOverview">http://wiki.apache.org/cassandra/ArchitectureOverview</a><br>
    <br>
    <b>Isolation</b><br>
    NOTHING is isolated; because there is no transaction support in the
    first place.&nbsp; This means that two or more clients can update the
    same row at the same time.&nbsp; Their updates of the same or different
    columns may be interleaved and leave the row in a state that may not
    make sense depending on your application.&nbsp; Note: this doesn't mean
    to say that two updates of the same column will be corrupted,
    obviously; columns are the smallest atomic unit ('atomic' in the
    more general thread-safe context).<br>
    Refs: None that directly address this explicitly and clearly and in
    one place.<br>
    <br>
    <b>Durability</b><br>
    Updates are made durable by the use of the commit log.&nbsp; No worries
    here.<br>
    Refs: Plenty.<br>
  </body>
</html>

--------------040601070305030006030201--