cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tupshin Harper <>
Subject Re: Read/Write consistency issue
Date Fri, 10 Jan 2014 23:13:26 GMT
It is bad because of the risk of concurrent modifications. If you don't
have some kind of global lock on the document/row, then 2 readers might
read version A, reader 1 writes version B based on A, and reader 2 writes
version C based on A, overwriting the changes in B. This is *inherent* to
the notion distributed systems and multiple writers, and can only be fixed
1) Having a global lock, either in the form of a DB lock (CAS for Cassandra
2.0 and above), or some higher level business mechanism that is ensuring
only one concurrent reader/writer for a given document
2) Idempotent writes by appending at write and aggregate on read. For
time-series and possibly counter style information, this is often the ideal
strategy, but usually not so good for documents.

For the counters scenario, idempotent writes, or the rewrite of counters
(which use idempotent writes behind the scenes) are probably good solutions.

Concurrent editing of documents, on the other hand, is almost the ideal
scenario for lightweight transactions.


On Fri, Jan 10, 2014 at 5:51 PM, Robert Wille <> wrote:

> Interested in knowing more on why read-before-write is an anti-pattern. In
> the next month or so, I intend to use Cassandra as a doc store. One very
> common operation will be to read the document, make a change, and write it
> back. These would be interactive users modifying their own documents, so
> rapid repeated writing is not an issue. Why would this be bad?
> Robert
> From: Steven A Robenalt <>
> Reply-To: <>
> Date: Friday, January 10, 2014 at 3:41 PM
> To: <>
> Subject: Re: Read/Write consistency issue
> My understanding is that it's generally a Cassandra anti-pattern to do
> read-before-write in any case, not just because of this issue. I'd agree
> with Robert's suggestion earlier in this thread of writing each update
> independently and aggregating on read.
> Steve

View raw message