Nested transactions; optimistic CC advantages

Nested transactions

• Nested transaction: a transaction made of sub-transactions in a tree. The top-level transaction contains child transactions, which may contain their own children. Sub-transactions at the same level can run concurrently, and a sub-transaction can abort without aborting its parent; the parent may retry or choose another action. Example: a book trip transaction with sub-transactions book flight, book hotel, book taxi. If the taxi booking fails, the parent can try another company.

Rules of nested transactions:

• A sub-transaction commits only provisionally; its result becomes permanent only when all its ancestors commit up to the top level.
• If a parent aborts, all its sub-transactions abort, even those that provisionally committed.
• A child sees the parent's changes, but the parent does not see the child's until the child commits.

Advantages: extra concurrency (parallel children), better failure handling (a child failure can be recovered inside the parent), and modular structure.

Optimistic concurrency control

Optimistic concurrency control (Kung and Robinson) assumes conflicts are rare, so transactions proceed without locks and are checked for conflicts only when they want to commit. A transaction goes through three phases.

1. Working phase: it reads and writes tentative copies of objects (private versions). Reads see the last committed values; no locks are taken. The system records the read set and write set.
2. Validation phase: when the client requests commit, the server checks for conflicts with other transactions that overlapped in time. If validation fails, the transaction is aborted (or conflict resolution is used).
3. Update phase: if validation succeeds, tentative versions are made permanent (written to permanent storage) and the transaction commits.

Validation (backward validation): transaction Tv is checked against earlier overlapping transactions Ti that committed before Tv started validation. Rules:

• If Ti writes an object that Tv reads (Ti's write set ∩ Tv's read set ≠ ∅), validation fails, because Tv read stale data.
• Otherwise Tv passes validation. (Writes are applied in commit order, so write-write conflicts cannot occur.)

Forward validation checks Tv's write set against the read sets of still-active transactions; it allows a choice of aborting Tv or the others.

In a distributed system, each server validates its own part of the transaction during the first phase of two-phase commit, and all servers must validate in the same global order to avoid commitment deadlock and inconsistent serial orders.

Advantages

• No locking, so no deadlock and no lock overhead.
• High concurrency when conflicts are rare; with forward validation, read-only transactions always pass validation.
• Abort is cheap because nothing was written permanently.

Disadvantages

• Under heavy conflicts many transactions abort and restart; starvation is possible.
• Wasted work for aborted transactions.

Advantages over other methods