cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Peli <manuelb...@gmail.com>
Subject Cassandra atomicity/isolation/transaction in multithread counter updates
Date Sat, 16 Jun 2012 07:37:59 GMT
I'm in a pseudo-deadlock about Cassandra and
atomicity/isolation/transaction arguments. My simple question is: what
happens when two (or more) threads try to update (increment) the same
integer column value of the same row in a column family? I've read
something about row-level isolation, but I don't sure that is managed
properly. Any suggestions? (N.B. The updates requires a read of current
value before the update write. Otherwise counter column can be used, but in
my opinion the problem still remain).

My personal idea is described next. Because it's a real time analytics
application, the counter updates are inherent only the current hour, while
previous hours still remain the same. So I think that one way to avoid the
problem should be to use a RDBMS layer for current updates (which support
ACID properties) and when the hour expires consolidate data on Cassandra.
It's right?

Also in the case of RDBMS layer still remain the transaction problem: some
update on different column family are correlated and if even one fails a
rollback is needed. I know that Cassandra doesn't support transactions, but
I think that, playing with replication factor and write/read levels the
problem can be mitigated, eventually implementing an application level
commit/rollback. I read something about Zookeeper, but I guess that add
complexity and latency.

Mime
View raw message