Concurrency Control: Locks and Snapshots · seed 1 · A4, ink-friendly. The answer key prints on its own page for grown-ups.

Waiting locks or private snapshots

Computing · Data & Databases · ages 20-21
Name ______________________   Date ____________

  1. What happens in the growing stage of two-phase locking?

    • The transaction collects every lock it needs and releases none
    • The transaction releases locks and takes no new ones
    • The transaction runs with no locks at all

  2. What does isolation promise?

    • Every transaction runs truly alone on its own machine
    • Each transaction behaves as if it has the database all to itself
    • Transactions may freely mix their changes together

  3. Under snapshot isolation, a transaction reads from the picture taken when it started, no matter what others commit meanwhile.

    Circle one:   True   False

  4. Two transactions each hold a lock the other wants. What happens next?

    • Both finish at double speed
    • Neither moves, and the system cancels one side
    • Both automatically share the locks

  5. Why must a transaction not release a lock early and take another one later?

    • Another transaction could slip a change in between
    • Locks can never be released at all
    • Early release always crashes the database

  6. What price does the database pay for offering snapshots?

    • Keeping old row versions around for open pictures
    • Blocking every writer during long reports
    • Deleting all pictures once a day

  7. A friend says snapshots make all conflicts impossible. What is the best reply?

    • Correct, pictures remove every clash
    • Wrong for locks, but locks never wait either
    • Wrong, same-row writes from one picture still clash at commit

  8. Two transactions change the same row starting from the same picture. What must the system do at commit?

    • Accept both writes quietly
    • Delete the row entirely
    • Catch the clash and let only one win
LightMySky · lightmysky.comW1-mt_gOd17LRKel-s1

Answer key

For grown-ups. Fold this page away before handing over the rest.

Waiting locks or private snapshots W1-mt_gOd17LRKel-s1

  1. The transaction collects every lock it needs and releases none · Growing only collects locks, and shrinking only releases them.
  2. Each transaction behaves as if it has the database all to itself · Isolation keeps overlapping transactions from mixing, so each sees a private view.
  3. True · Each transaction keeps its consistent starting picture for all its reads.
  4. Neither moves, and the system cancels one side · That standstill is a deadlock, broken only by cancelling one side.
  5. Another transaction could slip a change in between · A gap between locks lets a second transaction change the private view.
  6. Keeping old row versions around for open pictures · Old versions must stay readable while any starting picture still needs them.
  7. Wrong, same-row writes from one picture still clash at commit · Snapshots remove waiting, not clashes: same-row writes still need commit-time detection.
  8. Catch the clash and let only one win · Snapshot systems sort out same-row clashes at commit time with a single winner.
Worksheet · LightMySky