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 by: 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. -Tupshin On Fri, Jan 10, 2014 at 5:51 PM, Robert Wille <rwi...@fold3.com> 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 <srobe...@stanford.edu> > Reply-To: <user@cassandra.apache.org> > Date: Friday, January 10, 2014 at 3:41 PM > > To: <user@cassandra.apache.org> > 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 > >
