Transaction Concept

Definition

A transaction is a sequence of one or more database operations (reads and writes) that must be treated as a single, indivisible logical unit of work — it either completes entirely or has no effect at all. This concept was introduced practically in Chapter 8 (TCL) and Chapter 11 (Data Modification Transactions); this chapter goes deeper into the formal model behind it.

How It Works

The canonical example remains a bank transfer: debiting one account and crediting another are two separate SQL statements, but they represent ONE real-world action ("transfer money"). A transaction groups them so the database guarantees: either both statements' effects become permanent, or neither does — there is no possible outcome where money leaves one account without arriving at the other.

Edge Cases and Pitfalls

• A transaction can consist of a SINGLE statement — every individual INSERT/UPDATE/DELETE is technically its own transaction when running in autocommit mode (22.12), even though multi-statement transactions are what most people picture when they hear the word.
• The "logical unit of work" boundary is a business/application decision, not something the database infers automatically — the database only enforces atomicity/consistency for whatever statements you explicitly group; grouping the WRONG set of statements (too few, missing a related update) is a design mistake the database can't catch.
• A transaction's guarantees (the ACID properties, 22.4) apply regardless of how many statements it contains or how long it takes — but see 22.13 for why VERY long-running transactions have real practical costs even though they remain technically correct.

Key Takeaways

• A transaction groups operations into one indivisible logical unit — all-or-nothing.
• Even a single statement is technically its own transaction under autocommit.
• Choosing which operations belong in one transaction is a design decision the database doesn't make for you.