Return to the lecture notes index
February 22, 2008 (Lecture 17)


Exam #1

...will be oth this afternoon. It is due at 11:59PM one week from today. Please submit as you do a lab -- please use a common file format and simple pagination. We care about the quality of your thoughts -- not your graphic design capability :-)

Timestamp Ordering

Another approach to preventing inconsistency in light of concurrency is known as inconsistency avoidance. Instead of preventing inconsistency in the transaction manager, before the transaction is executed, inconsistency avoidance allows the transaction to execute, but causes it to abort if it cannot complete execution without violating the isolation property.

The most common approaches in this category are based on logical timestamps. As transactions enter the system, they are given a timestamp. This timestamp is used to determine which operations can be completed and which operations should cause a transaction to be aborted.

To implement this approach, we need a few things:

Given this information, the scheduler can speculate and allow operations to execute tentatively. These operations will only become visible if they are eventually commited. Furthermore, it is possible that they may be aborted as the result interference from other operations.


Since reads cannot conflict with each other, we don't need to worry about read-read conflicts. Instead, when a new read operation is received, we only need to worry about a conflict with a write. If the read operation arrives too late, after a write with a later timestamp has committed, the reading transaction must be aborted -- it is impossible to undo the committed write to deliver the proper value.

If the read operation arrived in a timely way, we add it to the queue. If there is an earlier pending write, we wait for this write to commit or abort before returning a value. Otherwise, we hope for the best and return the value to the transaction (this allows the transaction to speculatively continue). If an earlier write shows up and commits before the transaction using the speculative read value commits, the reading transaction must abort -- that's why we enqueued the read for record keeping.


Just as with reads, a write request must be rejected if it arrives late. In other words, if the writing transaction's timestamp is earlier than the object's WR, the transaction must be aborted. The write must also be aborted if a prior read has already been committed. This is because we can't undo the read and give the reading transaction a new value.

If a write request arrives in a timely way, we place it into the queue according to its time.


If a transaction that contains only a reads commits, three things need to happen:

It is important to note that a read cannot commit if it was queued behind a pending writes at the time that it was issued. This is because it must wait for those writes to commit or abort -- the transaction is blocked until this happens and the write can return. The only pending writes that might need to be aborted are those that arrived late-ish -- after the speculative read returned a value. Please remember that they were not aborted, because the read had not committed -- there was still hope (until now).

When speculative writes are committed, transactions associated with reads and writes that occured before it must be aborted and removed from the queue. This is because their effect will be forever lost once the write modifies the object. The write operation, itself, must be removed from the object's queue, and any reads that were blocked waiting for the write to commit or abort can be unblocked and permitted to return a value to their transaction. Of course the WR time should be updated.


If a transaction containing a read is aborted, the read is removed from the object's queue -- no other action needs to be taken, since read cannot affect other transactions. If a transaction containing a write is aborted, it should be removed from the object's queue and any writes which were blocked awaiting the write should be allowed to continue.

Optimistic Transaction Scheduling

During the last couple of classes, we discussed 2PL as an example of inconsistency prevention and timestamp ordering as an example of inconsistency avoidance. Today we are going to discuss another approach, known as validation

Instead of preventing inconsistency by structuring safe transactions using locks, or avoiding deadlock by aborting transactions that might go awry as soon as a problematic operation appears, we are going to optimistically speculate and complete each transaction. Once the transaction is speculatively done, the system will validate it to ensure that the result, as a whole, is safe.

This approach will consider a transaction to have a three phase life cycle: execution, validation, and update.

In order to validate a transaction, certain timestamps are needed:

The validation protocol itself is a two-phase protocol initiated by the trasnaction manager. It sends a message containing TS, TV, and the set of read objects (RO) and write objects (RO) to participating transaction managers (transaction managers on systems executing subtransactions). The transaction is validated only after the coordinating transaction manager has received the OK from all participants.

Each participant will use the following rules to determine if the transaction can be validated: