22C:118 Fall 2004 Week 13 Summary 22C:118 Fall 2004 Week 13 Summary

  1. Monday: a lecture on databases, the basics of transactions, the ACID property and recovery, and the need for scheduling algorithms that guarantee serializability.
  2. On Wednesday, the topic of two-phase locking (2PL) and how it guarantees serializability (but not recoverability, which motivates strict 2PL) was explained. Then, finally, we are ready for the main issue related to networking, how to manage transactions in distributed databases. The protocol for two-phase commit was introduced.
  3. Friday's lecture examined the two-phase commit protocol and how transactions are coordinated so that ACID properties hold even in a distributed database. A special case of this, now seen in many commercial applications, is a replicated database, where deciding the order of transaction commits is related to barrier synchronization (that is, before the next transaction can be run, all sites have to finish the current transaction). In non-replicated distributed databases, there is opportunity for more parallelism because different transactions can operate at different sites, on unrelated parts of the database. The two-phase commit protocol requires that all the participants of a transaction be in a kind of uncertain state, between the time they are ready to commit and actually get a message from the coordinator to do the commit (or, they could get abort messages, which is why things are uncertain). During the period of uncertainty, updates to the database are pending, and the variables to be updated are locked. Thus, transactions potentially block other transactions during the period of uncertainty. This drawback can be addressed by using yet another phase, leading to a three-phase commit protocol - that protocol is described in the reading.