The Transactions Concept: Virtues and Limitations

Jim Gray

 

Transactions – Atomic, Consistent, Durable  (Possibly isolated if non-nested)

 

real actions (that affect the external phsyical world and cannot be undone and/or should not be redone), are only done after transaction commit.  The device that does the real world action needs to record the fact that it is done, and should ignore any commands to redo it.

 

Systems fail—no matter how hard you try... if you do build a perfect system, it will be used by imperfect people who will make mistakes (bad data entry) that will cause it to fail.  So you need redundancy to protect from failure.  Mirroring disks can increase the MTTF (mean time to failure of the system) from the failure time of one disk to the combined failure time of all the disks.

 

Highly available systems are yet another problem.  Need to be able to hot swap hardware (and potentially even software as well).  Process pairs.

 

Write-ahead checkpointing.

 

Undo/Redo Logs.

 

Fail-fast: a module either operates correctly, or detects it owns failure and does nothing.  (How is this different from fail-stop?)

 

Update in place is a bad idea.  Accountants always use double-entry bookeeeping for reduncancy, and never “erase” errors in place... they always add a second entry correcting the error.

 

Time-Domain Addressing: write out new versions of data objects as they evolve.  never delete or update in place.  Write out timestamps with data objects any time that data is modified or accessed, and abort any transactions that attempt to “rewrite history.”  We need to do writes every time that objects are even just accessed because otherwise a transactions may read a value that was written by some transaction that attempted to rewrite history.  Commit records are written out once a transaction has been validated (ensured that it never attempted to rewrite history). 

 

Problems with time-domain addressing:

1)      reads require writes to disk (very expensive)

2)      long running transactions in a system with high concurrency are likely to have many aborts

3)      timestamps force a single granularity.  (modifying an entire relation is hard)

 

Vs. Locking/Logging: Most disk blocks hold current state of the system, and logs hold history.  Transactions obtain locks on objects before they operate on them.  Only serializable schedules are accepted by the system.

 

Use Two-phase commit if any one of n participants in a transaction can unilaterally decide to abort.  

 

Two-phase locking to avoid deadlocks.

 

Locking on different granularities of object is possible by organizing them into a hierarchy. 

 

Gray purports that time-domain and locking/logging are really more similar than we think modulo performance issues.

 

Problem with nested transactions is that the actions of sub-transactions may need to be viewable to the outside world.  I think this differs from the way that they were described in Liskov’s paper on CLU, in which the actions of sub-transactions were only viewable to the parent transaction—not the outside world. 

 

Gray also sees long-lived transactions as a problem because deadlocks increase “with the square of the number of concurrent transactions and the with quad (4th power) of the size (length) of the transactions.”

 

Integration with programming languages—include begin-transaction, commit-transaction, and abort-transaction in PLs?  Disk overhead too much... I guess so!

 

Peter principle – “every good idea is generalized to the point of inapplicability”