What is a Transaction?

A transaction in a database represents a single, logical unit of work. It ensures that a series of operations either completes successfully as a whole or fails entirely, leaving the database unchanged. This concept is fundamental to maintaining the database's integrity, ensuring consistency, and allowing safe retries without side effects.

A transaction can either be:

• Committed: All operations within the transaction are successfully executed and changes are permanently saved.
• Aborted: If any operation fails, all changes made by the transaction are undone, leaving the database in its original state.

ACID Properties of Transactions

1. Atomicity: Transactions are "all-or-nothing" operations. If one part fails, the entire transaction fails, ensuring no partial changes occur.
2. Consistency: Transactions move the database from one valid state to another, maintaining all defined rules, constraints, and relationships.
3. Isolation: Multiple transactions occurring simultaneously do not interfere with each other, preserving the correctness of operations.
4. Durability: Once a transaction is committed, its changes are permanent, even in the case of system failures.

These characteristics are often referred to as the ACID properties.

Why Are Transactions Necessary?

Imagine a scenario where Person A transfers $10 to Person B's account. The following steps are required:

1. Debit $100 from Person A's account.
2. Credit $100 to Person B's account.

Without transactions:

• If the debit operation succeeds but the credit operation fails due to a network issue, the database ends up in an inconsistent state. Person A's balance is reduced, but Person B does not receive the funds.

With transactions:

• The system ensures that either both operations succeed (commit) or neither is applied (abort), preventing any inconsistency.

States of a Transaction

1. Active: The transaction begins execution. At this stage, operations are being carried out but changes are temporary and reside in memory.
2. Partially Committed: The transaction completes its final operation but has not yet saved changes to permanent storage.
3. Committed: Changes are written to the disk, making the transaction permanent and durable.
4. Failed: An error occurs during execution, leading the transaction to halt.
5. Aborted: After a failure, all changes made by the transaction are rolled back, and the database is restored to its previous state.
6. Terminated: The transaction ends, either successfully (committed) or unsuccessfully (aborted).

Weaker Transaction Guarantees

While traditional relational databases implement strict ACID properties, some systems provide weaker guarantees to improve performance or scalability:

• Single-object guarantees: Some NoSQL databases ensure atomic operations only on a single record or document, not across multiple.
• Atomic increments: Systems like Redis allow atomic updates to numerical values, avoiding race conditions during concurrent modifications.
• Compare-and-Swap (CAS): An atomic operation that ensures a value is only updated if it matches an expected value, preventing conflicts.

These weaker guarantees are designed to optimize specific use cases but do not offer the same level of reliability as full transactions.