How do DataStax Enterprise transactions differ from RDBMS transactions?

The location of
the cassandra.yaml file depends on the type of
installation:

Package installations

/etc/dse/cassandra/cassandra.yaml

Tarball installations

installation_location/resources/cassandra/conf/cassandra.yaml

DSE does not adhere to ACID (Atomicity, Consistency, Isolation, Durability) transactions with
rollback or locking mechanisms, but offers atomic, isolated, and durable transactions with
eventual and tunable consistency that allows the user decide how strong or eventual they want
each transaction’s consistency to be.

As a non-relational database, DSE does not support joins or foreign keys, and consequently does
not offer consistency in the ACID sense. For example, when moving money from account A to B, the
total in the accounts does not change. DSE supports atomicity and isolation at the row-level, but
trades transactional isolation and atomicity for high availability and fast write
performance.

Atomicity

In the DSE database, a write operation is atomic at the partition level, meaning the
insertions or updates of two or more rows in the same partition are treated as one write
operation. A delete operation is also atomic at the partition level.

For example, if using a write consistency level of QUORUM with a replication factor of three,
the database replicates the write to all nodes in the cluster and waits for acknowledgement from
two nodes. If the write fails on one node but succeeds on another node, DSE reports a failure to
replicate the write on that node, but the replicated write that succeeds on the other node is
not automatically rolled back.

DSE uses client-side timestamps to determine the most recent update to a column. The latest
timestamp always wins when requesting data, so if multiple client sessions update the same
columns in a row concurrently, the most recent update is the one seen by readers.

Note: The
timestamp for all writes is UTC (Universal Time Coordinated).

Isolation

DSE write and delete operations are performed with full row-level isolation. This means that a
write to a row within a single partition on a single node is only visible to the client
performing the operation. The operation is restricted to this scope until it is complete. All
updates in a batch operation belonging to a given partition key have the same restriction.
However, a batch operation is not isolated if it includes changes to more than one
partition.

Durability

Writes in the DSE database are durable. All writes
to a replica node are recorded both in memory and in a commit log on disk before they are
acknowledged as a success. If a crash or server failure occurs before the memtables are flushed
to disk, the commit log is replayed on restart to recover any lost writes. In addition to the
local durability (data immediately written to disk), the replication of data on other nodes
strengthens durability.

You can manage the local durability to suit your needs for consistency using commitlog_sync in the
cassandra.yaml file. Set the option to either
periodic or batch.