sorry having to ask again something to Cassandra again and I would very much appreciate your adivce:

I have read this: <http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic> and are comletely lost and wondering:

Is it really true, that in Cassandra WRITES on ONE SIGLE NODE for ONE ROW-KEY (with MANY COLUMNS to be updated in the SAME COLUMNFAMILY, using batch\_mutate) are NOT ISOLATED against a READ on the SAME NODE 
to the SAME ROW-KEY'S COLUMNS, guaranteeing that a read does not ready "partly changed data"? Example:

```
Current Status:     [KEY=1 , ColumnName=A with Value=A , ColumnName=B with Value=B] on Node 1
Client A => Writes: [KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=D] on Node 1

```

ATOMICITY:

According to the cassandra docs, Writes are Atomic for the Client doing the write:
The write above will either be completely successfully or fail completely!? 
Something like
 `[KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=B]` (=half of the column updates succeeded, 
but the other half was not yet applied/faild) can not be the RESULT of the Write in case of an error? 
Is this correct?

ISOLATION:

Is it really true, that even on ONE SINGLE NODE (here Node 1) writes are not isolated for someone reading the same ROW on the same Node?
As desctribed above, if Client A has updated half of its columns to be changed (here ColumnName=A with Value=C ),
is it really true, that another Client B connectiong the Node 1 will then indeed see the record as

```
Client B => Reads:  [KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=B] on Node 1

```

And some milliseconds later,reading again it will see ?

```
Client B => Reads:  [KEY=1 , ColumnName=A with Value=C , ColumnName=B with Value=D] on Node 1

```

.

Why are Updates not isolated on a per Node Basis? 

For mee this seems to be quite easy and cheap?
Why is there no in memory lock held on Node 1, that KEY=1 is currently in the process of being updated so a read can wait to finish this write?
(This would be only a very small overhead, as the lock is locally held in memory on the Node1, and could be configured that the Reading client can accept the "lock" or simply read a dirty value?
So it is something like a "Configurable Isolation Level"? If I need high performance I ignore locks/disable them and if I need isolation on a per node basis and accept the
negative performance impact, then I waite for the in memory lock (on node 1) to be released? (Note, I am not talking about culstered/distributed-locks, but locks that guarantee on one single maching that a write is isolated on a per row-key basis!)

Or is Isolation different in regard to "changing existing columns" versus operations that "append/add columns". So that chaing columsn (as in the example above are isolated) but adding new columsn is not isolated. From my point of view, changing existing columns must be isolated/atomic.... Adding columsn is not su much required to be isolated...

The question why I am asking: If things like depicated above can happen, that reads really read partitially changed records, what 
usecases are then legitimate for nosql/cassandra? This means any kind of random column data can exist on a per row basis as the columsn 
might be in any random read/write state? I hardly know of any data and use case that is allowd to be changed "arbitrarily" on per row
basis.

Thank you very much!!!
jens