Servers must record all the effects of committed transactions and none of the effect of aborted transactions.

The following present the problems associated with aborting transactions (in the context of the banking example).

Dirty reads

• Caused by the interaction between a read operation in one transaction and an earlier write operation in another transaction on the same object. 

Recoverability of transactions

• If transaction has committed after it has seen the effects of a transaction that subsequently aborted, the situation is not recoverable. 
• Strategy is to delay commits until after the commitment of any other transactions whose uncommitted state has been observed.
  
  

  Figure 11: A dirty read when transaction T aborts
  

Cascading aborts

• In Figure 11, suppose that transaction U delays committing until after T aborts.
• U must abort as well.
• But, if any other transactions have seen the effects due to U, they too must be aborted.
• To avoid cascading aborts, transactions are only allowed to read objects that were written by committed transactions.
• Any read operation must be delayed until other transactions that applied a write operation to the same object have committed or aborted.
  

Premature writes

• Related to write operations on the same object belonging to different transactions.
• Consider two setBalance transactions, T and U, on account A.
  • Before transactions, the balance of account A was $100.
  • T set the balance to $105 and U set the balance to $110.
  • If U aborts and T commits, the balance should be $105.
  • Some database system implement the abort action by restoring ‘before images’ of all the writes of a transaction.
  • ‘before image’ of T’s write is $100 and ‘before image’ of U’s write is $105.
  • If U aborts, we get the correct balance of $105.
  • U commits and then T aborts, balance should be $110, but ‘before image’ of T’s write is $100, we get the wrong balance of $100.
  • T aborts and then U aborts, ‘before image’ of U’s write is $105 and we get wrong balance – the balance should be $100. 
• Write operation must be delayed until earlier transactions that updated the same objects have either committed or aborted.
  
  
  

  Figure 12: Overwriting uncommitted values
  

Strict executions of transactions

• The executions of transactions are called strict if the service delays both read and write operations on an object until all transactions that previously wrote that object have either committed or aborted. 
• Enforces isolation property.

Tentative versions

• For a server of recoverable objects to participate in transactions, it must be designed so that any updates of objects can be removed when a transactions aborts.
• All of the update operations performed during a transaction are done in tentative versions of objects in volatile memory.
• Each transaction is provided with its own private set of tentative versions of any object that it has altered. 
• The tentative versions are transferred to the objects only when a transaction commits, by which time they will also have been recorded in permanent storage.