Understanding Transaction Fundamentals: ACID, Isolation Levels, Spring Transaction Propagation, and Distributed Transaction CAP Theory

0x01: Basic Elements of Transactions (ACID)

Atomicity: Once a transaction starts, all operations must either complete fully or not at all; if an error occurs, the transaction rolls back to the state before it began, making the transaction an indivisible whole, like an atom in chemistry.

Consistency: The database's integrity constraints remain intact before and after the transaction; for example, when A transfers money to B, it is impossible for A's account to be debited without B receiving the amount.

Isolation: At any given time, only one transaction may request the same data, and transactions do not interfere with each other. For instance, while transaction A is withdrawing cash from a card, transaction B cannot transfer to that card until A finishes.

Durability: After a transaction commits, all its updates are permanently stored in the database and cannot be rolled back.

0x02: Transaction Concurrency Problems

Dirty Read: Transaction A reads data modified by transaction B, but B later rolls back, leaving A with dirty data.

Non‑repeatable Read: Transaction A reads the same data multiple times, while transaction B updates and commits the data in between, causing A to see different results.

Phantom Read: Administrator A changes all student grades from numeric scores to letter grades, while administrator B inserts a new record with a numeric score at the same time; after A finishes, the new record appears as a phantom.

Non‑repeatable reads and phantom reads are easy to confuse: non‑repeatable reads focus on modifications, while phantom reads involve inserts or deletions. Solving non‑repeatable reads requires locking the affected rows; solving phantom reads requires locking the whole table.

MySQL Transaction Isolation Levels

Isolation Level

Dirty Read

Non‑repeatable Read

Phantom Read

Read Uncommitted

Yes

Yes

Yes

Read Committed

No

Yes

Yes

Repeatable Read

No

No

Yes

Serializable

No

No

No

MySQL’s default isolation level is repeatable‑read ; Oracle’s default system isolation level is read‑committed .

0x03: Spring’s Five Transaction Isolation Levels

ISOLATION_DEFAULT: Uses the underlying database’s default isolation level.

ISOLATION_READ_UNCOMMITTED: Allows a transaction to see uncommitted changes from other transactions, leading to dirty reads, non‑repeatable reads, and phantom reads.

ISOLATION_READ_COMMITTED: Guarantees that only committed changes are visible, preventing dirty reads but still allowing non‑repeatable and phantom reads.

ISOLATION_REPEATABLE_READ: Prevents dirty reads and non‑repeatable reads; phantom reads may still occur.

ISOLATION_SERIALIZABLE: The most stringent level; transactions are executed sequentially, preventing dirty reads, non‑repeatable reads, and phantom reads.

0x04: Spring’s Seven Transaction Propagation Behaviors

PROPAGATION_REQUIRED: Join an existing transaction if present; otherwise start a new one.

PROPAGATION_SUPPORTS: Join an existing transaction if present; otherwise execute non‑transactionally.

PROPAGATION_MANDATORY: Must join an existing transaction; throws an exception if none exists.

PROPAGATION_REQUIRES_NEW: Always start a new transaction, suspending any existing one.

PROPAGATION_NOT_SUPPORTED: Execute non‑transactionally and suspend any existing transaction.

PROPAGATION_NEVER: Execute non‑transactionally; throw an exception if a transaction is active.

PROPAGATION_NESTED: Execute within a nested transaction if a transaction exists; otherwise behave like PROPAGATION_REQUIRED .

0x05: Distributed Transaction CAP Theory

Consistency: Guarantees strong data consistency; every read returns the latest committed data.

Availability: Every request receives a response within a reasonable time.

Partition Tolerance: The system continues to operate despite network partitions between nodes.

In distributed systems, partition tolerance (P) is a basic requirement; monolithic applications can be CA systems. Micro‑service architectures typically aim for AP, satisfying availability and partition tolerance, which introduces challenges for strong consistency—often addressed through distributed transaction mechanisms.