There is no undo or redo log in Cassandra. From Cassandra perspective if the
operation gets logged in commit log, it is considered committed.
Remember the eventual consistency...
On Mon, Mar 28, 2011 at 6:21 PM, Saurabh Sehgal wrote:
> I have seen this question pop up once or twice in mailing
I have seen this question pop up once or twice in mailing lists regarding
atomicity when using batch_mutate() operations. I understand that the
operations in batch_mutate() should be idempotent and do not get rolled back
on failures. However, a client crashing (due to machine issues, networking
iss
Hi, Patricio,
It's hard to comment on your original questions without knowing details of
your own domain specific data model and data processing expectation.
W.R.T. lumping things into one big row, there is a limitation on data model
in Cassandra. You got CF and SCF. That is, you have only 2 leve
2010/7/20 Patricio Echagüe :
> Would it be bad design to store all the data that need to be
> consistent under one big key?
That really depends how unnatural it is from a query perspective. :)
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Ca
Hi, regarding the retrying strategy, I understand that it might make
sense assuming that the client can actually perform a retry.
We are trying to build a fault tolerance solution based on Cassandra.
In some scenarios, the client machine can go down during a
transaction.
Would it be bad design to
Hi, Stuart,
If I may paraphrase what Jonathan said, typically your batch_mutate
operation is idempotent.
That is, you can replay / retry the same operation within a short timeframe
without any undesirable side effect.
The assumption behind the "short timeframe" here refers to: there is no
other c
typically you will update both as part of a batch_mutate, and if it
fails, retry the operation. re-writing any part that succeeded will
be harmless.
On Thu, Jul 8, 2010 at 11:13 AM, Stuart Langridge
wrote:
> Hi, Cassandra people!
>
> We're looking at Cassandra as a possible replacement for some
Hi, Cassandra people!
We're looking at Cassandra as a possible replacement for some parts of
our database structures, and on an early look I'm a bit confused about
atomicity guarantees and rollbacks and such, so I wanted to ask what
standard practice is for dealing with the sorts of situation I ou
