Where OCC performs well
- Low conflict rates: a huge database with a uniform access pattern — a billion tuples where two concurrent transactions rarely touch the same one — makes OCC "fantastic," very fast (
40:19). - Read-only transactions are even faster, because no shared locks are taken (
40:57). - With multi-versioning (next lecture), read-only transactions don't even need a private workspace (
40:57).
The costs
| Overhead | Detail |
|---|---|
| Copying into the private workspace | 2PL's expensive lock table is replaced by expensive memory copying. Deltas mitigate but do not eliminate it (41:08, 41:29) |
| Validation + write phases | Latches must be taken to protect shared data structures while installing changes → bottleneck (41:29) |
| Cost of aborts | Much higher than under 2PL. Under 2PL, failing to get the first of a billion locks wastes nothing. Under OCC you update all one billion items, reach commit, and only then discover the conflict — the whole transaction must roll back (41:42, 42:04) |
| No early exit | You must run a transaction to completion just to learn whether it will succeed (42:14) |
The degenerate case
- If every transaction updates the same tuple, OCC and 2PL are indistinguishable: both degenerate to single-threaded execution and no protocol can do better (
42:14).
Choosing between protocols
- Which protocol is better "depends on many different factors" and is genuinely hard to pick (
42:14,1:03:40). - Academic literature proposes adaptive protocols — run OCC while conflicts are low, dynamically switch to 2PL when conflicts rise (
1:03:40). - No real system implements adaptive switching: implementing one protocol correctly is already so hard that supporting both correctly in a PostgreSQL or MySQL is a major challenge (
1:03:40,1:04:09).