ContentsThe library

What a Transaction Promises

Both Doctors Checked That Someone Else Was on Call

Last timeDoing It With Snapshots

Two transactions, two different rows, both reading a rule that spans several rows and each one breaking it on the strength of the other holding it up.

The previous lesson ended with one surviving gap, and it is specific enough to

construct on purpose. It has a name, write skew, and once you have seen it once

you will recognise the shape in your own code.

The example to carry

A hospital rota. The rule is that at least one doctor must be on call at all

times. Two doctors are on call and both feel unwell at the same moment.

FIG 1Two doctors, two transactions, one broken rule
stepstepdoctor Ayers transactiondoctor Bell transactiondoctors on callwhat happened
11takes a snapshottakes a snapshot2Both transactions begin within the same second. Each records the state of the database as it is now, which is two doctors on call.
22counts doctors on call: 2counts doctors on call: 22Both counts are correct. Both read the same committed state because both snapshots were taken before either wrote anything.
332 is more than 1, so proceeding2 is more than 1, so proceeding2Both checks pass. The logic is right: it is safe to go off call as long as somebody else is on call, and somebody else is.
44writes its own row to off callwaiting its turn2A write to the Ayers row. No other transaction has written that row, so there is no version conflict and nothing to report.
55committedwrites its own row to off call1A write to the Bell row. A different row. Still no version conflict, because the detection compares versions of one row and these are two rows.
66donecommitted0Both committed, both individually correct, and nobody is on call. No error was raised anywhere and nothing in any log says what went wrong.
6 steps
Six steps and no mistake in either transaction. Each read a consistent snapshot, applied a correct rule to it, and wrote one row that nobody else had touched. Run either one alone and the rule holds. Run them in either serial order and the second one sees one doctor on call and refuses. Run them together on snapshots and the rule is broken with no error, which is exactly the definition of a failure that is not serialisable.

Three ingredients are needed and all three are necessary. Both transactions

read an overlapping set of rows. Both check a rule over that set. And each

writes a different row.

The lesson stops here

5 more paragraphs to go

You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.

The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.

See the planThe contents

This is the reading half

Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.

The contents

The rest of this course

  1. 01The Power Can Fail Between Your Two Statements
  2. 02Both of Them Read 10 and Both of Them Wrote 11opening only
  3. 03Reading Something That Was Never True, and Three Relativesopening only
  4. 04Your Database Is Not Using the Level You Think It Isopening only
  5. 05Take Them All Before You Give Any Backopening only
  6. 06Keep the Old Row and Nobody Has to Waitopening only
  7. 07Both Doctors Checked That Someone Else Was on Callyou are here
  8. 08Name the Rule First, Then Pick the Weakest Level That Holds Itopening only

Read alongside