Single-Object vs. Multi-Object Transactions

Key Insight

Atomicity and isolation are vital even for operations on a single data object. For instance, when writing a 20 KB JSON document to a database, these guarantees ensure that a network interruption after only 10 KB of data is sent does not leave a partially written, unparseable fragment. Similarly, a power failure during a disk write should not result in a spliced old and new value, nor should another client read a partially updated value during an ongoing write. Storage engines universally provide single-object atomicity and isolation, typically using logs for crash recovery and object-level locks for concurrency.

Many databases provide atomic operations like incrementing a counter or compare-and-set for single objects, eliminating the need for application-level read-modify-write cycles and preventing lost updates. These operations are crucial for concurrency safety on individual items. However, these are distinct from full transactions, which are generally understood as mechanisms for grouping multiple operations on multiple objects into a single execution unit. Marketing terms like 'lightweight transactions' for single-object operations can be misleading.

Multi-object transactions are indispensable for maintaining data integrity across related data. Examples include ensuring foreign key references remain valid across tables in relational databases, synchronizing denormalized data across multiple documents, or updating secondary indexes. Without multi-object transactions, handling error scenarios becomes significantly more complicated, and data can easily become inconsistent (e.g., an email appearing as unread in a mailbox but the counter showing zero). While some distributed databases have abandoned multi-object transactions due to implementation complexity, they are often necessary for many application patterns.