Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "Counters" page has been changed by Alexis Wilke: http://wiki.apache.org/cassandra/Counters?action=diff&rev1=16&rev2=17 Comment: Fixed a couple of plurial forms, and replace "insert" with "add" which is much more appropriate for a counter! {{{ [default@test] create column family counterCF with default_validation_class=CounterColumnType and replicate_on_write=true; }}} - Setting the `default_validation_class` to `CounterColumnType` indicates that the column will be counters. Setting `replicate_on_write=true` will be optional starting in 0.8.2, but a bug made it default to false in 0.8.0 and 0.8.1, which is unsafe. + Setting the `default_validation_class` to `CounterColumnType` indicates that the columns will be counters. Setting `replicate_on_write=true` will be optional starting in 0.8.2, but a bug made it default to false in 0.8.0 and 0.8.1, which is unsafe. ==== Incrementing and accessing counters ==== @@ -86, +86 @@ == Technical limitations == * If a write fails unexpectedly (timeout or loss of connection to the coordinator node) the client will not know if the operation has been performed. A retry can result in an over count [[https://issues.apache.org/jira/browse/CASSANDRA-2495|CASSANDRA-2495]]. - * Counter removal is intrinsically limited. For instance, if you issue very quickly the sequence "increment, remove, increment" it is possible for the removal to be lost (if for some reason the remove happens to be the last received messages). Hence, removal of counters is provided for definitive removal only, that is when the deleted counter is not increment afterwards. This holds for row deletion too: if you delete a row of counters, incrementing any counter in that row (that existed before the deletion) will result in an undetermined behavior. Note that if you need to reset a counter, one option (that is unfortunately not concurrent safe) could be to read its ''value'' and insert ''-value''. + * Counter removal is intrinsically limited. For instance, if you issue very quickly the sequence "increment, remove, increment" it is possible for the removal to be lost (if for some reason the remove happens to be the last received messages). Hence, removal of counters is provided for definitive removal only, that is when the deleted counter is not increment afterwards. This holds for row deletion too: if you delete a row of counters, incrementing any counter in that row (that existed before the deletion) will result in an undetermined behavior. Note that if you need to reset a counter, one option (that is unfortunately not concurrent safe) could be to read its ''value'' and add ''-value''. * `CounterColumnType` may only be set in the `default_validation_class`. A column family either contains only counters, or no counters at all. == Further reading == - See [[https://issues.apache.org/jira/browse/CASSANDRA-1072|CASSANDRA-1072]] and especially the [[https://issues.apache.org/jira/secure/attachment/12459754/Partitionedcountersdesigndoc.pdf|design doc]] for further information about how this works internally (but note that some of the limitation fixed in these technical documents have been fixed since then, for instance all consistency level '''are''' supported, for both reads and writes). + See [[https://issues.apache.org/jira/browse/CASSANDRA-1072|CASSANDRA-1072]] and especially the [[https://issues.apache.org/jira/secure/attachment/12459754/Partitionedcountersdesigndoc.pdf|design doc]] for further information about how this works internally (but note that some of the limitations fixed in these technical documents have been fixed since then, for instance all consistency level '''are''' supported, for both reads and writes).
