Foundations — Locking — shared, exclusive, intent locks

Before you can read the parent note fluently, you need to earn every word it throws at you. This page builds each one from absolute zero, in an order where nothing appears before it is defined.

1. What is a "transaction"?

The picture: a sealed envelope holding several instructions. You either open and run the whole envelope, or you throw it away unopened.

Why the topic needs it: locks are held by transactions. "Who is waiting?" and "who owns this lock?" always means which transaction. Without this unit, the word "conflict" has no owner.

The letters T1, T2 you see everywhere in the parent are just names for two such envelopes running at the same time. Related depth lives in ACID Properties and Two-Phase Locking.

2. What is a "data item"? (rows, pages, tables)

The picture: a Russian nesting doll. The table contains pages, a page contains rows. A lock can grab the outer doll (table) or one inner doll (row).

Why the topic needs it: the entire "intent lock" idea only makes sense because objects nest. If you lock a row inside a table, someone eyeing the whole table needs a way to notice. That is why the parent links Lock Granularity.

3. "Concurrent" — at the same time

The picture: two timelines running side by side, with arrows crossing between them where they touch the same data item.

Why the topic needs it: if only one transaction ever ran at a time, locks would be pointless — nobody to conflict with. Locks exist purely to make concurrency safe. The precise "how safe" is tuned by Isolation Levels.

4. The three anomalies (the enemy locks fight)

The parent lists three bad things. Let's name each with a plain picture.

The picture: two hands reaching for the same jar; whoever's hand arrives second smudges what the first was relying on.

Why the topic needs it: these three are the exact reasons S and X locks are split the way they are. Every compatibility ❌ in the parent's table is there to prevent one of these three.

5. Notation: $x$, $O(1)$, $O(n)$

Why the topic needs it: the whole point of intent locks is turning an $O(n)$ row-by-row scan into an $O(1)$ single flag check. Without this notation you can't feel why they're worth the trouble.

6. "Acquire", "hold", "release", "block"

The picture: a single key on a hook. You take it (acquire), keep it in your pocket (hold), hang it back (release). Anyone else who needs that key stands in line (block).

Why the topic needs it: "T2 waits" in every parent example means exactly this blocking. When two transactions each block waiting for the other, you get a deadlock — a whole topic of its own.

7. Compatibility — "can two coexist?"

The picture: a table (grid) where the row is "what I want" and the column is "what's already there"; a ✅ means "go ahead," a ❌ means "wait." This grid is the compatibility matrix the parent shows.

Why the topic needs it: every locking decision the engine makes is a single lookup in this grid. Master this idea and the parent's two tables become obvious.

Prerequisite map

Read the map top-down: transactions + concurrency create the danger (anomalies); S/X locks are the cure; granularity + Big-O explain why intent locks are added; the compatibility matrix ties it all into the parent topic. Deeper reading branches into Two-Phase Locking, MVCC, and Isolation Levels.

Equipment checklist