All posts by Kuba Łopuszański

InnoDB Data Locking – Part 3 “Deadlocks”

In this  blog series, I’m describing how InnoDB locks data (tables and rows) in order to provide illusion to clients that their queries are executed one after another, and how this was improved in recent releases.
In InnoDB Data Locking – Part 1 “Introduction” I’ve introduced basic concepts required to understand current post:

  • databases, tables, rows (like files on a shared drive, spreadsheets inside a file, and rows inside a spreadsheet)
  • serializability of transactions (ability to explain states observed over time with a convincing story about relative order of parallel operations)
  • timeouts (for misbehaving lock owners, and to resolve deadlocks)
  • reader-writer lock (shared/exclusive access rights)
  • starvation (permanent inflow of readers starving a writer waiting for its turn)
  • queueing (FIFO, or priority)
  • read views (read-only snapshots which allow stale reads concurrent to new writes)
  • granularity of a lock (access right to everything vs.

InnoDB Data Locking – Part 2.5 “Locks” (Deeper dive)

All together now

Let’s now put together all that we’ve learned in InnoDB Data Locking – Part 2 “Locks” about table and record locks to understand following situation: