Transaction Concurrency-Control Foundations

Use this skill when you need shared vocabulary + decision lenses for transaction concurrency control before analyzing a specific protocol or trace.

This skill is most useful when you catch yourself asking:

• “What exactly is the anomaly / conflict here?”
• “What does the protocol need to prevent, and what metadata would prove it?”
• “Is this abort required for correctness or just conservative?”

Quick Reference (pick the next file to read)

If you need…	Read
Core terms and what “commit/abort” means in histories	transaction-concepts.md
A crisp definition of the bug pattern (lost update, dirty read, write skew, phantoms)	concurrency-control-problems.md
A guarantee taxonomy (serializable vs SI vs strict serializable; opacity if relevant)	anomaly-and-isolation-taxonomy.md
Dependency/conflict edge types (rw/wr/ww; anti-deps; visibility)	conflict-taxonomy.md
Where a mechanism fits (locking vs TO vs OCC vs MVCC vs SSI vs hybrid)	protocol-family-overview.md
Concrete protocol mini-specs (2PL/TO/OCC/MVCC/SSI/TicToc)	representative-protocols.md

Router: from “protocol cues” to what to read

When you have a protocol description or trace fields but don’t know what family it is, route by cues.

A. Is the protocol primarily blocking or aborting?

• Blocking on conflicts, lock modes (S/X), deadlocks mentioned → go to 2PL in representative-protocols.md
• Nonblocking execution + commit-time validation → go to OCC (and often TicToc/SSI live here too)

B. Does it assign a fixed transaction timestamp early?

• Per-txn fixed TS(T), and objects store RTS/WTS → go to Basic Timestamp Ordering
• Per-txn snapshot/start_ts + multiple versions → go to MVCC / Snapshot Isolation

C. Do reads choose a version from a version chain?

• Yes (visibility rule, begin/end timestamps, “as of snapshot”) → go to MVCC
• No, single current version plus per-key metadata → go to TO / OCC / TicToc-like

D. Do you see read timestamp extension or “valid-through” metadata?

• Fields like rts (read-valid-through), extension checks, or “extend rts if unchanged” → go to TicToc

E. Do you see dependency / anti-dependency tracking?

• Explicit rw anti-deps, “dangerous structure”, serialization-graph edges → go to SSI

F. What’s the proof object?

• Locks prove exclusion → 2PL
• Per-key RTS/WTS prove timestamp order → TO
• Read-set version check proves stability → OCC
• Visibility from snapshot + version chain proves consistent reads → MVCC/SI
• Anti-dep edges / dangerous structure prove no cycles → SSI
• Per-key wts/rts interval + extend-if-unchanged proves read validity at chosen commit_ts → TicToc

Minimal Working Vocabulary (keep this tiny)

When analyzing a trace or protocol, keep a running record with these nouns and edges:

transactions: T1, T2, ...
objects/keys: x, y, ...
versions: x@wts=..., x@ver=...
operations: R(x@...), W(x@...), commit(T), abort(T)
dependencies:
  T_i ->wr T_j   (T_j read from T_i's write)
  T_i ->rw T_j   (T_i read a version that T_j later overwrote; anti-dep)
  T_i ->ww T_j   (T_j overwrote T_i on same object)

If you can’t name the version read/written, you’re still in “story mode,” not “proof mode.”

Checklist: classify a protocol decision

Use this checklist before labeling an abort “unnecessary” or a commit “unsafe”:

• Claimed guarantee: serializable? strict? SI? opacity?
• What the transaction read: object + which version/timestamp evidence.
• What changed by validation time: overwrite? timestamp extension? dependency edge?
• What order would make it safe: a serial order or a timestamp assignment.
• What evidence is missing: did the protocol lack history/versions to prove safety?

Common Pitfalls

• Mixing scopes: per-key counters and timestamps often cannot order different keys.
• Equating “row order” with “happened-before”: log order can be buffered/merged.
• Assuming abort == anomaly: aborts can be conservative proof failures, not unsafe histories.