By J. H. Saltzer, 1996.

Here is a possible discussion idea to follow whichever lecture discusses commit
records, transaction ID's, and value histories (depending on the exact order of
topics that could be either in the second or the third lecture on this topic):

It is interesting to try to program an atomic audit for a bank with the tools
discussed in lecture.  There are two ways, with very different properties.  Ask
the class to identify the different properties:

1.  Low priority:  Assume that each record contains the transaction ID
that last modified that record.  Then, for each account, read the
balance and the transaction ID and make a list of {account, balance, ID}
triples.  Then, do it again. Compare the two lists to see if any ID's
changed.  If not, we have a consistent set of balances.  Add them up and
declare success.  If any ID's did change, the set of balances is
inconsistent.  Replace the first list with the second and try again.
Keep repeating until two successive scans show no differences.

2.  High priority.  Create a transaction for the audit.  Lock each
account, read its balance, and hold its lock until the audit is
complete.  If the attempt to acquire an account lock encounters another
active transaction, wait for the other transaction to unlock the
account, then continue.

The low-priority scheme has the potential to not make progress.  The busier the
bank, the longer it will take for an audit to find a quiet period long enough to
complete.  But it doesn't get in anyone else's way.

The high-priority scheme has the potential to deadlock with any transaction that
involves two accounts (one of which the auditor has locked, the other of which
the transaction has locked) so one would probably also insist on either a
deadlock prevention scheme or else that  non-auditing transactions timeout and
retry.  And by the time it is done, it will have tied up every account in the
bank, preventing anyone else from doing any work.  But it gets the audit over
with.

A third scheme, based on a presumed ability to read values from the
version history,  seems even more interesting:  The auditor first
identifies the lowest-numbered uncommitted transaction.  It then
subtracts one from that number and considers the result to be the audit
point.  Now, it reads the balance that every account had at the audit
point.  For any account that didn't get updated at the audit point, use
its previous balance in the history.  That set of balances is guaranteed
to be consistent.  (Why?)